This would be viewed as censorship by many people, you do know that Ordinals are also Segwit transactions, the Segwit upgrade was widely accepted because it gave everyone the same chance, to change your address -- you get the discount, but with this approach, you are not separating Segwit transactions into two groups, one that gets a discount (because some people want that) and others who don't (again, because some people don't them to).
Censorship? I don't think so. But it would be of course arbitrary. It would be a bold statement screaming "We want Bitcoin to be a payment coin, not a contract coin nor data cloud storage platform!". 
However: Those who use other scripts than those benefitting from the additional discount would not be punished at all. They would even be benefitted partly too, because if "payment-style" transactions have less weight, the weight which is then "liberated" can also be used for things like Ordinals and it's likely that initially they'll pay less fees too. But payment transactions would benefit proportionally much more from such an hypothetical change.
Also, it's not the first time such a "discrimination of a particular user group" happened. When OP_RETURN was introduced it was limited to 80 bytes and to one output per transaction - because the devs thought that larger data storage should be disincentived.
I want to point out however that this "proposal" is only an example for a possible path which could be explored, it's not that myself I would favour such a rule over other possibilities (my own opinion is actually that it's better to concentrate on solutions like sidechains and LN, and in the long term: use a zero-knowledge-based approach to verify the blockchain, which would liberate nodes from the need to store all data). It's to show the theoretical possibility to increase the block size without making data storage-type spam easier. Personally I think it's too difficult to really determine which are "desired" or "undesired" kinds of usage. However: If such a change would be necessary, it could be probably applied via soft fork - I see no technical problem.
This also opens the door to other types of transaction-biased discounts, transactions of >x amount should get y discount and the others won't, it's like creating a VIP membership on the blockchain.
Well first these protocol changes would have to be approved by miners. Miners would probably not necessarily against such a policy: while the average fees would level down a bit, there are more transactions they could fit in a block, so the total fees collected per block could increase. A "VIP club" like the one you describe, in contrast, would not make sense for miners. They don't care about the amounts transacted, they care about the fees.I get what you probably mean though, it could lead to endless senseless discussions about "desired" and "undesired" use cases. So the best thing would actually if such a discount could be applied to transactions which effectively have a resource-saving function (like Segwit had.)
The main problem I see with this approach is that effectively penalizing smart contracts and similar transactions (such as LN and sidechain related transactions, as you already pointed out), is throwing the baby out with the bath water.
Of course one could include transactions with OP_CSV and multisig, which are required for Lightning, to the list of discounted transaction types. But see my response above to mikeywith: I don't think this approach is ideal.Also the fact that Ordinals inscribers (inscriptors?) appear to be largely fee insensitive would probably make any form of monetary penalty largely ineffective.
That wasn't the case initially. It was even argued in this thread (and/or other discussions?) that despite of the high transaction count, the fee level stood relatively low (often below 20 sat/vByte) for a long time. IMO it's the bubbles some of the tokens have seen that led to the big fee increase and thus to the sensation that Ordinals users are fee insensitive.