So you can guarantee the Runtime API won't become like the Editor API in the future where only the documented exposed stuff is accessible while the rest is obfuscated and impossible to use ?
The point of the warning is: we reserve the right to do that! You should not be surprised if we do, because we warned you.
People messing with undocumented internals causes disasters. This has happened. Who gets the blame, takes the reputational damage, and has to spend hours picking up the pieces and helping desperate customers whose projects are ruined? Us. How do we avoid that ever happening in the first place? By enforcing a properly supported API with language-enforced encapsulation. The fact the runtime does not already do this is in my view an architectural mistake, and we are continually running the risk of some change causing disaster. I would like to fix this architectural mistake (as it largely is for the editor, so we have removed the risk there), but I don't know if or when we would do that. As ever we are extremely busy and have to constantly prioritize lots of different work. If we did do it, I promise that we will try to do it in a responsible fashion, slowly rolling it out gradually in the API over time and where feasible fixing compatibility issues as and when they come up; but as the warning says, we reserve the right to say "sorry, you shouldn't have done that".
To be clear, obviously I don't want to make one big change that breaks everything deliberately - that would be irresponsible. But the problem is this could happen anyway for some other reason, such as simply by accident, or due to some major upgrade. In general the longer you leave it the worse the compatibility problems will be, so in general, the sooner we can bite the bullet and start imposing proper encapsulation and long-term supported public APIs, the better it will be in the long run.
For what it's worth, this is how we develop Construct itself. Supporting software for 10+ years is tricky, and involves taking great care and judgement over every change over a period of many years. We almost never use any undocumented, internal or experimental APIs in any of the other third-party software or services we use, and where we do so, we do it in the most minimal possible way and with the understanding it could be 100% broken at any point in the future and then it's entirely our responsibility to deal with it. In general if we need something but it's not supported, we file a feature request, and go away and do something else. Maybe it's added eventually, and maybe not. But we don't hack it in, because in the long run that's a recipe for disaster, and that's not how you build software that still works 10+ years later.
I think there is a simple analogy for all this: if you use undocumented internals, you void your warranty. If you buy a brand new car with a warranty, but open up the engine and put in a part you designed yourself, you void your warranty. It's the manufacturer's way of saying "we can't possibly support what you've done, so you're on your own now". If the car then explodes and renders it worthless, tough luck, that was on you. Welding down the engine cover so nobody can get to it is however a step too far in the other direction. Being able to access the engine, but specifying what is supported (such as a list of manufacturer-approved parts), is a sensible middle-ground. The software equivalent is: stick to the public, documented, supported APIs, and you're fine; use undocumented internals and you void your warranty, anything at all could happen for any reason, you're on your own, and you should understand that is a real risk and act accordingly.