Intentando entender REST

Desde la primera vez que escuché el término servicio REST, siempre lo han utilizado como contrapunto a los servicios web SOAP. Es decir que un servicio REST es una url que recibe peticiones y responde sin usar XML, usando principalmente JSON. Además, si para realizar las peticiones utiliza los verbos http: post, put, delete y get se dice que es RESTful.

"Una mentira repetida mil veces termina siendo verdad" - Goebbels.
No fue hasta que escuché el podcast Hanselminutes: Misunderstanding REST with Mike Amundsen cuando descubrí que REST no era lo que me estaban contando.
REST es un estilo de arquitectura o de diseño informático. No existen unas normas o reglas fijas que definan claramente qué es REST o qué no.
Dentro de este estilo arquitectónico Roy Fielding es considerado por muchos como el referente. Fielding fue el primero en utilizar el término REST en su trabajo para su doctorado: "Architectural Styles and the Design of Network-based Software Architectures". En concreto en el capítulo 5: Representational State Transfer (REST)

Para explicar este estilo Fielding utiliza HTTP como ejemplo. En el documento se enumeran una serie de condiciones:

• Debe ser Cliente/Servidor
• La comunicación debe realizarse sin estado, es decir que una petición debe contener toda la información necesaria para que el servidor la procese. Y lo mismo aplicado a la respuesta.
• La información debe ser explicita o implícitamente cacheable
• Interfaz uniforme:
• Los recursos deben estar identificados (en http los recuros se identifican por la URI)
• La manipulación de los recursos se realiza mediante la representación (en http los mensajes indican el tipo de contenido, por ejemplo text/html, application/xmlapplication/xml)
• Los mensajes deben ser autodescriptivos: si requiere autenticación, si son cacheable, etc.
• Y un último punto que no me quedó muy claro "hypermedia as the engine of application state" y que desarrolla aquí
• El sistema debe permitir añadir capas, de tal forma que un cliente no sepa si se está conectando directamente al servidor. Por ejemplo, el sistema debe permitirla implantación de un balanceador de carga.
• Código bajo demanda, como el javascript en html, el cliente se descarga el código y luego lo ejecuta. (Esta condición no es obligatoria para que un sistema sea REST.)

¿Qué es REST?
Si he de ser sincero no me ha quedado de todo claro. Lo que sí puedo decir es que REST no es un sistema para hacer CRUDs.
HTTP es el mejor ejemplo de REST y así que un API WEB que siga el estilo REST debe aprovechar al máximo todas las características de HTTP, utilizar metadatos para de las cabeceras para indicar comportamientos, resultados de operaciones, datos de autenticación o de formatos del cuerpo. Por otro lado el cuerpo solo debe utilizarse para intercambiar información.

La pregunta que yo me hago es: La gente utiliza el termino REST o RESTful para decir que un servicio web no es SOAP, cuando la definición de REST de Fielding es dice otra cosa completamente diferente, ni habla de servicios web. ¿Merece la pena o el esfuerzo explicar que están utilizando el término de forma incorrecta? ¿o como ya está expandida esta acepción del término no merece la pena meterse en a discutir estas cosas si al final nos estamos entendiendo?