I think you guys have a wrong impression how things do/can work (no offence) 
.
We do not “restrict” anything, but only the Raspberry Pi kernel and bootloader, maintained by RPi developers and distributed via official RPi package repository, provide reliable device tree overlays and a way to toggle Bluetooth that way. If it’s about Bluetooth, on all other SBCs I’m aware of it is enabled OOTB (we just install Bluez tools on top). The method of how things are/can be done on RPi is unique and cannot be just “revealed” on other SBCs, but a completely new method would need to be added.
Note that mainline Linux is not designed to compile for a single SBC only (which would be highly inefficient anyway), but the configuration flags/options always define an architecture and SoC family. You can basically see it here in the official Linux sources: dts « boot « arm64 « arch - kernel/git/stable/linux.git - Linux kernel stable tree
So you enable flags for 64-bit ARM + Rockchip, and with this the compiled kernel does natively support all 64-bit Rockchip ARM SBCs (which have mainline Linux support). Armbian just follows this instead of patching the sources in a way to build an own kernel for each and every SBC (impossible to maintain). You can also see that there are no device tree overlays at all in Linux sources. Those are all added by Armbian developers or community members who have time and mood to figure things our and test them etc. And since there is naturally one kernel for an SoC family, logically it contains all overlays for this SoC family. Armbian solves this partly by using prefixes, i.e. rk3399- for the beginning of the overlay file name to define it being compatible with the Rockchip RK3399 SoC only, which works well in all cases where it is not a specific peripheral which requires PCB support from a specific SBC instead (but Armbian usually does not ship such kind of overlays anyway).
Now since overlays are not maintained within the Linux kernel, there is no guarantee that they are still functional after a major kernel upgrade and Armbian does not have the capabilities to test each overlay with each Linux version on each SBC and in case update them. This leads to this unpleasant situation where they may or may not work or break things, or break after any next kernel upgrade. But who do you want to blame for since those overlays are developed/maintained in peoples spare time?
So it is not at all about our scripts, but about the fact that overlays are badly maintained and cannot be relied on. If we do now just add a GUI to enable them easily, people will start reporting issues if they do not work, even that it is outside of our responsibility, scope and abilities to deal with those issues. So based on this it seems not wrong to me to keep this somewhat a hidden and hence unsupported (users own responsibility) feature.
So based on this, I thought a little more and we talked a bid about it in our weekly meeting yesterday. Since there is no way we can maintain a per-SBC menu with overlays known to work, as we do not own all SBCs and even then had no capacities to test them with every kernel upgrade (as Armbian doesn’t have either), a generic menu to just list all overlays with the right prefix is the only way (just like Armbian does with their armbian-config tool). But we must make it clear that there is zero guarantee that they work and that they can break the board/booting, so it is each users full own responsibility and one must have a plan how to access the /boot/dietpiEnv.txt to manually remove the overlay in case the board does not work.
How is it better when you have to download and compile overlays first, compared to just adding them to a config file to enable them? Again, it is not at all about the way how overlays are provided, but only about the question whether they are working reliably or not. Of course Radxa (hopefully) does test them on their SBCs with their own kernel when providing them. They also do not need to test them on new Linux upgrades, because they never upgrade their Linux builds for a specific SBC, which is a much larger problem IMO.
I hope I made it clear now that there are no “standard” overlays, but that those are all written by developers or community members in their spare time, so the problem is the source of reliable overlays, not the question how to provide/compile/enable them.