There’s no technical reason on GL.inet’s side. They could make it happen - but I suppose they’re busy with device support and porting OpenWrt 19.07 right now.
The GL interface is great if you want to be able to do the basic things it’s been designed for. Anything more complex, and the system breaks, since it expects certain things to be the way it’s been hard-coded. These things can be turned dynamic of course, but it’s extra work that’s often not worth the time, as most users will only be using the GL interface anyway.
Let’s go for a concrete example. Your router sets up the local wireless APs on 2.4GHz band (name is hardcoded to wlan0), and 5GHz band (name is hardcoded to wlan1), and a wireless client/STA interface to connect to an uplink router (let’s say it’s called wlan-sta). Then you wander into LuCI, delete all wireless interfaces, and create a STA definition to connect to your router. This STA mode interface then becomes wlan0. You wander back to the GL interface, and bam, it dies - because the status screen itself was expecting wlan0 to be an AP, tried to load its data according to that, and found STA instead, which in turn screws up the UI.
All of this can be avoided by dynamically querying the interfaces (e.g. instead of directly requesting wlan0 for 2.4GHz AP, you could ask uci to get you the first ap type interface on radio0, which is still not a surefire way of getting the exact AP you want, but avoids possible confusions), and of course the same can be applied to WireGuard itself. The question here is simply if it’s worth the investment of time and resources.
Regardless, what you’re asking for is possible - but not on the GL interface, and not without affecting it.