When it says that it is difficult to implement the server correctly, I think it's an immediate red flag. We went through this with HTTP (nginx retrying non-idempotent requests anyone), and SMTP. I think the lesson learned that any future protocols should require really good specs and every implementation should follow them.
It's not saying it is difficult to implement the server correctly. It is saying "the server side may be hard to implement well". There's a subtle difference there. The reason is not protocol complexity or a poor spec. The protocol is simple and well documented. Rather it is an admission that implementing a queueing server can be hard, depending on the semantics you choose to implement, and certainly is harder than the client code.
The protocol is perhaps not the most efficient. It's primary benefit is the simplicity and level of support in various environments. Having Stomp support for a message broker is a great way of adding low-effort interoperability.
A Stomp based message broker was my first serious Ruby project a decade or so ago, and getting the server "right" for our use case took ~500 lines of code (using sqlite for queues marked persistent), which is incidentally about the same size as the spec.
