No - not a limitation of Groovy; much more complicated than that.
SmartThings doesn’t execute our Groovy directly. It goes into what they call a “sandbox” - really just a bunch of pre-processing and other layers so it can be run in the SmartThings Cloud alongside everyone else’s SmartApps. The cloud consists of execution environments and persistent storage (Cassandra or other AWS compatible database(s), …).
Traditional global variables would only be possible if each Customer had their own Java Virtual Machine (still in the cloud and/or local) but this would take a horrendous amount of resources.
Using “Virtual Devices” sorta an appropriate way to solve this, except they could have provided a “Global Variable Device” instead of the customer having to manually spawn these themselves.
Well - You can supposed store extra data in the Location object; but that’s an entirely unofficial hack with its own issues.
For valid security reasons, not only is each SmartThings Account (and Location) supposed to be secured from all others; but every Device and SmartApp must not be able to see or affect any other (except for parent-child). Just like one App on your phone can’t talk directly to any other App.
In fact, one other smart home platform vendor designed their Hub on Android and each SmartApp was to be a distinct App.
In short? This stuff is hard. SmartThings came up with a “pretty darn good” architecture to launch the product. But it probably should have gone through a couple major evolutions since then; but then how could existing users continue to work?