I find a helpful way of looking at it and resolving the debates is to see it as a pile of engineering trade offs.
All engineering is all about trade offs anyway.
You do it this way… you win these things…. but you lose those… choose wisely according to what you are doing.
An instructive set of examples is the history of version control systems and seeing which way they made these trade offs that REST is talking about and why… RCS, CVS, svn, git/hg…
So if REST is a pile of trade offs not doing pure REST is not the end of the world…. you merely lose the benefits of that particular trade off.
That may hurt you, it may not.
So what is that pile of trade offs trying to achieve?
Where neither the control and evolution of the server, nor the behaviour and evolution of the clients is under control of any unified organization.
You cannot command one client to come, nor prevent a million from coming if they so choose, and there is always another server but one click away.
If you designing a network for such an environment…. REST is what you end up with.
If you are designing an API that will work and grow when you cannot force your clients to upgrade, nor as a client prevent the server from changing…. a REST API is the maximally decoupled solution you end up with.
You can choose to discard one or more of the trade offs in the pile… but you will always lose something (and win something else).
(The classic one is a REST client should never bookmark, but always navigate from the root. If you do bookmark you risk breaking if the server evolves, but you gain speed. It’s a trade off… you win something and you lose something. Do it with both eyes open.)
If you are not designing for such an environment, eg. the client and server is under the rigid control and evolution and deployment of a single team….. REST will probably get in your way. Doing something else will be simpler.
Conversely, your simpler solution will still require rigid control as it scales multiple teams and organizations….