In a perfect world, yes, but from what we've seen in recent months this would only lead to larger Ordinals Inscriptions rather than an increased transaction throughput. Maybe someone can correct me if I'm wrong, but if I'm not mistaken the current congestion is largely due to Ordinals, rather than regular transactions.
You're largely correct, while Ordinals transactions are not occupying as much space as some months ago, there was an increase since last weekend, where again some 300.000 transactions per day were BRC-20. In addition, there probably was an increase of "normal payment transactions" too due to seasonal reasons.There could however be a way to circunvent the problem of space filling by Ordinals and other data-spam transactions: create a special discount for simple payment transactions which only consist of inputs and outputs with the simplest possible P2WPKH script.
Currently we have a two-tier discount scheme due to Segwit:
Tier 1: Segwit witness data (ratio 1/1 in terms of Byte/vByte)
Tier 2: All other transaction data (ratio 1/4)
We could advance to a three-tier scheme:
Tier 0: Simple payment transactions (ratio 2/1), i.e. they would have a weight of half of the Segwit witness data*
Tier 1: Other Segwit witness data (1/1)
Tier 2: All other transaction data (1/4)
This would have the effect that we would increase the maximum block size to a maximum of 8 MB, but only if it was filled exclusively by Tier 0 data.
Of course that would not be an easy change. In the case of Witness data, there's actually a reason why it got the discount: because in the long run it is cheaper to store, process and transmit this kind of data as Segwit Witnesses are a separate section in transactions and don't clutter the UTXO set. In contrast, the "Simple Payment Transaction discount" would be completely arbitrary, it isn't cheaper to process. It would be a convention to favour this kind of transaction and to make payments cheaper than other contracts.
If there's any problem with that approach please criticise it, after all I'm not really an IT expert.
(A point I've noticed myself is that if implemented that way is that Lightning transaction and sidechain peg-ins/outs for example would not benefit from this discount. They could be included but that would make the measure very complex.)(*the 2/1 is probably not the best way to do it due to the mandatory division, but the idea should become clear. An alternative could be to add the Segwit discount to all parts of the transaction if it only contains transaction data. This would not increase the block size but would fill the 4 MB more often.)