This has oft been discussed and proposed over many years within the TTN community and in discussion with the TTI core team, with many of the reasons you give amongst those points in favour.
Full disclosure: I would benefit massively from such a policy change as I have >>50 GW’s deployed (UK, EU & US) on the community network under my own name and have provided >150 more to community users and collaborators who support and host additional deployments around the world, however, as a community contributor I accept that exceptions to the policy are not allowed.
The reality is that it would be challenging to monitor and ‘police’ IRL. And more importantly there are a few technical reasons and issues why it may continue to be limited on the ‘free’ instance.
To give just a couple:
LoRaWAN is a broadcast system where the nodes just transmit and messages are picked up by all GW’s in range. Having your own GW would not mean only your GW hears your devices shout. Rather experience shows that in many places - especially in larger town and city or higher density deployments any given message may be heard by many GW’s - all of which will forward to TTN LoRaWAN backend (TTS Sandbox). Hearing via 4,5,6 GW’s is typical and in many places I have seen >>10-12 GW’s regularly hear the message. In some places, especially if there are adjacent or geographically overlaid peering LoRaWAN networks, the number of receiving GW’s can be far higher. Each message has to be handled by the LNS and messages de-duped. Allowing a user to increase TX rates would therefore not just be e.g. say 2x rate allowed then 2x through put on their own GW but could be 20, 24 or even >100 more messgaes to be handled for just dedupe. The impact would scale significantly. And whilst you would add 1 unit of GW capacity, in reality you are potentially absorbing far more capacity across the network as each hearing GW has to allocate receive/decode resources to handle, and in the case of any associated downlinks (Join accepts, ADR command, confirms, network/device management etc.) the impact is even higher as >95+% of GWs are simplex and can’t listen when transmitting to service your devices.
To provide a timely response to ANY node transmitting at any time essentially all device credentials for all devices (so DevAddrs, associated Network, Application and Device Keys etc.) have to be held in memory for immediate action - you cant wait to pull from remote HDD or even SSD storage to handle the message. Increasing the usage rate for any given device therefore has a significant impact on the operation & scale of the backend memory requirements.
Hence the decison to limit use under FUP on the freely provided Community network, which is increasingly positioned as a testbed and development network vs an open free to use/abuse resource.
The corollary to this of course is that as a broadcast technology is that other devices on alternate networks, or even on TTS based private networks the GW’s will still hears all device TX’s in range and will have to forward to their associated LNS, but atleast the back end will not need to be scaled to fully handle all of the messages received and many will not be set for peering or will not be recognised as ‘valid’ messages for the given LNS instance - TTS Sandbox in our Community case - and can simply be dropped at the appropriate point.
No doubt this will be revisited again in the future and TTI, who fund this free offering, may yet relax the rules but I would not have high hopes at this point as costs continue to escalate.
In the meantime for all the benefitial reasons you state please do go ahead and deploy and add to the Community network and help us all improve and benefit from the increased capacity - remember “You are the Network” 
So I often advise that rather than FUP being a limit or restriction in many cases it is really a guide to good practice and many of the private network deployments I have supported over the years have stuck with the same limit or possibly increased very slightly where the use case has demanded it…… just my 2 penneth!