Nadie en la comunidad REST dice que REST es fácil. HATEOAS es solo uno de los aspectos que añade dificultad a una arquitectura REST.
La gente no hace HATEOAS por todas las razones que sugieres: es difícil. Agrega complejidad tanto al lado del servidor como al cliente (si realmente desea beneficiarse de ello).
SIN EMBARGO, miles de millones de personas experimentan los beneficios de REST hoy. ¿Sabes cuál es la URL de "pago" en Amazon? Yo no. Sin embargo, puedo pagar todos los días. ¿Ha cambiado esa URL? No sé, no me importa.
¿Sabes que le importa? Cualquiera que haya escrito una pantalla eliminó el cliente automatizado de Amazon. Alguien que probablemente haya rastreado minuciosamente el tráfico web, leído páginas HTML, etc. para encontrar qué enlaces llamar, cuándo y con qué cargas útiles.
Y tan pronto como Amazon cambió sus procesos internos y la estructura de la URL, esos clientes codificados fallaron, porque los enlaces se rompieron.
Sin embargo, los internautas ocasionales pudieron comprar todo el día sin apenas problemas.
Eso es REST en acción, simplemente aumentado por el ser humano que es capaz de interpretar e intuir la interfaz basada en texto, reconocer un pequeño gráfico con un carrito de compras y darse cuenta de lo que eso realmente significa.
La mayoría de la gente que escribe software no hace eso. A la mayoría de las personas que escriben clientes automatizados no les importa. A la mayoría de las personas les resulta más fácil arreglar a sus clientes cuando se rompen que diseñar la aplicación para que no se rompa en primer lugar. La mayoría de la gente simplemente no tiene suficientes clientes donde importa.
Si está escribiendo una API interna para comunicarse entre dos sistemas con soporte técnico experto y TI en ambos lados del tráfico, que pueden comunicar cambios de manera rápida, confiable y con un cronograma de cambios, entonces REST no le compra nada. No la necesita, su aplicación no es lo suficientemente grande y no es lo suficientemente duradera como para importar.
Los sitios grandes con grandes bases de usuarios tienen este problema. No pueden simplemente pedirle a la gente que cambie su código de cliente por capricho al interactuar con sus sistemas. El programa de desarrollo de los servidores no es el mismo que el programa de desarrollo del cliente. Los cambios abruptos en la API son simplemente inaceptables para todos los involucrados, ya que interrumpen el tráfico y las operaciones en ambos lados.
Por lo tanto, una operación como esa probablemente se beneficiaría de HATEOAS, ya que es más fácil de versionar, más fácil de migrar para los clientes más antiguos, más fácil de ser compatible con versiones anteriores que no.
Un cliente que delega gran parte de su flujo de trabajo al servidor y actúa sobre los resultados es mucho más robusto a los cambios del servidor que un cliente que no lo hace.
Pero la mayoría de la gente no necesita esa flexibilidad. Están escribiendo código de servidor para 2 o 3 departamentos, todo es para uso interno. Si se rompe, lo arreglan y lo han incluido en sus operaciones normales.
La flexibilidad, ya sea de REST o cualquier otra cosa, genera complejidad. Si lo quiere simple y rápido, entonces no lo hace flexible, simplemente "hágalo" y listo. A medida que agrega abstracciones y desreferenciación a los sistemas, las cosas se vuelven más difíciles, más placa de caldera, más código para probar.
Gran parte de REST falla en el punto de viñeta "no lo vas a necesitar". Hasta que, por supuesto, lo hagas.
Si lo necesita, utilícelo y utilícelo como está diseñado. REST no está moviendo cosas de un lado a otro a través de HTTP. Nunca lo ha sido, es un nivel mucho más alto que ese.
Pero cuando necesita REST, y usa REST, entonces HATEOAS es una necesidad. Es parte del paquete y la clave de lo que hace que funcione.