The throughput of possible UTXOs may not have changed but the throughput of transactions with non-trivial scripts has. Now we can construct a transaction with a 2 of 3 multisig and spend it without including anything in the scriptsig. Reducing transactions with complex scripts to an anyone-can-spend transaction with a small scriptpubkey does increase the transaction throughput for the most common use-case for example, which is just paying to a public key hash (https://dune.com/murchandamus/bitcoins-utxo-set)

This limit no longer exists for taproot transactions and it is now consensus valid for a transaction to fill up an entire block

This is the most reasonable approach in my opinion

The data sources used to inspire this proposal is as poorly thought out as this idea. I'll focus on your citations as @ABCbits has already showed the gaping technical issues with your proposal through his questions.

The first citation you list, The hidden environmental costs of cryptocurrency (found at https://collections.unu.edu/eserv/UNU:9528/UN-IWEH_BTC_Report.pdf), uses information from your second citation, CBECI.

The first report even notes this and helpfully summarizes the methods used by the CBECI:

"First, the monthly electricity use for BTC mining in the 76 BTC mining nations monitored by CBECI between January 2020 to December 2021 was roughly estimated using the average monthly hashrate share of each country and the total monthly electricity use of the global BTC mining network. Then the average carbon, water, and land footprint of electricity generation in each BTC mining nation were estimated [41, 42] based on its energy supply mix data as reported by the International Energy Agency (IEA) and the environmental footprints of electricity generation from different sources using the scientific literature data on footprint valuesy [41, 42]. Multiplying the BTC electricity use in each country by its footprint values provided the carbon, water, and land footprint estimated of BTC mining for that country."

So even if all Bitcoin miners switched to using renewable energy today, the data collection method would still hold them responsible for the carbon footprint of their residing countries. For all we know this could already be the case, but the data isn't able to tell us.

It's almost academically dishonest to reference those numbers in any serious publication. The CBECI explicitly mentions these assumptions (https://ccaf.io/cbnsi/cbeci/ghg/methodology), so they can argue they don't hide it, but publishing this information with such uncertain methods in the first place should be condemned.

So an idea like CoinPool?

https://coinpool.dev/v0.1.pdf

Having the protocol be the least common denominator is exactly what the protocol architects should be striving for. Everything else is an implementation detail. To keep things truly decentralized the knowledge of how Bitcoin works should be spec driven. This allows every technical person to weigh in on the high level challenges of the protocol through documents like bips. A friendly environment towards more implementations also helps ensure a system of checks and balances where core devs can't dictate the direction of the protocol against the majority of user wishes just because they have market share.

A real-world case study of this approach can be showcased through web browsers. Sure most browsers are based on chromium but browsers like Safari and Firefox (and spin-offs like the Tor browser) have unique approaches to protocol implementations that many internet users value.