Tiens je ne connaissais pas cet article, merci de me le faire découvrir,
et autant la première partie est une compilation propre et relativement claire
des notions déja connues sur la thématique de OGC SFS 1.1.

Autant la partie conclusion est quant à elle pour le moins hétérodoxe,
(je la reprend ci après en vous citant, vu que c'est votre article):

Certes sur la partie OGC SFS 1.1 (soit environ 80 fonctions), sauf que PostGIS en implémente
au moins 150 de plus...

La seule implémentation de OGC SFS 1.1 corrrespond à la version 1.0 de PostGIS sortie en ... 2005

Rien ne vous empèche avec PostGIS de stocker en 4171 si bon vous sied.
Sachant que la seule différence entre EPSG:4326 et EPSG:4171 est le changement de l'ellipsoide WGS84 vers GRS80,
qui est non mesurable pour une utilisation classique en SIG.
(la transformation de l'un vers l'autre via proj4 renvoit d'ailleurs les même coordonnées)

Pour s'en convaincre:

SELECT   ST_AsText('SRID=4326;POINT(10.123456789 10.123456789)'::geometry) AS orig_4326,
              ST_AsText(ST_Transform('SRID=4326;POINT(10.123456789 10.123456789)'::geometry, 4171)) AS dest_4171;

Le fait de stocker dans une géométrie autorise à utiliser *toutes* les fonctions associées,
et pour celles sensibles au caractère non euclidien du référentiel, il suffit de rebasculer en geography.

On peut dans un cas classique reprojeter, mais vu qu'ici le paramétre de transformation (towgs84
est à 0,0,0) on peut directement surcharger à la volée le SRID dans une requête soit par exemple:

SELECT ST_Distance(ST_SetSRID('SRID=4171;POINT(1 2)'::geometry, 4326)::geography, 
                               ST_SetSRID('SRID=4171;POINT(2 3)'::geometry, 4326)::geography);

humm il suffit de caster à la volée, c'est effectivement un tantinet plus pénible à l'écriture,
mais en rien inopérant ou limitant.

Ex:

SELECT ST_Dimension(('SRID=4326;LINESTRING(1 1,2 2)'::geography)::geometry);

MakeValid n'est pas une fonction OGC SFS (ni en 1.1, ni en 1.2)

ST_MakeValid a été introduit dans PostGIS à partir de la 2.0
(cette version n'était pas encore sortie en stable à la date de la rédaction de votre article,
néanmoins elle était déjà présente dans la version de développement et documentée)

L'objectif de MakeValid est de rendre un objet géométrique conforme à sa représentation OGC SFS.
Concrétement cela concerne uniquement les polygones,
pas d'auto intersection, ni de trous chevauchant l'enveloppe externe du polygone...

Avant PostGIS 2.0 le workaround était de faire un buffer de 0.0 pour obliger GEOS a renvoyer une
géométrie valide à partir de ses données imparfaites.
(une bonne pratique est précisons le au passage, d'avoir des données valides en base)

Bref cet article s'il est une jolie compilation de l'existant, est résolument partial dans ses conclusions.

Si vous saviez comme je suis bien de votre avis ^^

Pour compléter le post didactique de Vincent,
on peut préciser que dans le cas particulier de PostGIS,
les paramètres utilisés pour reprojeter (lors d'un appel à ST_Transform)
sont contenus dans la colonne proj4text et non dans srtext.

Intérressant à savoir donc, si vous voulez rajouter un système de projection
ou modifier un paramètre d'une projection existante de la table spatial_ref_sys
(il arrive encore que certains codes (vraiment) peu usités soient mal configurés
pour leurs valeurs de proj4text)

Ce qui ne veut pas dire pour autant que l'on peut se passer de srtext,
vu que d'autres composants y font aussi appel (pgsql2shp,
autres outils SIG interopérable…)

La colonne proj4text, elle, ne fait pas partie du standard OGC SFS,
C'est donc plus un workaround de PostGIS qui reflète le fait que Proj4 ne sait pas,
à ce jour, parser du WKT.

Il avait été question d'écrire un parser au niveau PostGIS,
mais c'est en priorité basse (litote), dans la pile des actions à venir.

On pourrait imaginer un Google Summer of Code, sur ce sujet,
et à ce titre l'écrire directement pour Proj4.

Si vous vous sentez une envie particulière d'écrire un parser
(style flex/bison ou re2c/lemon) n'hésitez pas à vous manifester.