This approach to web performance smacks of someone who has never had to build an app under real world conditions. "It will be smaller if you rewrite your app to be AMP-first. No, scrap that, the PRPL pattern is in, we'll hold the PWA rewrite for next week" are not viable solutions for engineers at companies that aren't Google.
Try telling your marketing department that they can't integrate third party scripts through Google Tag Manager, or a VP that the SDK for that third party service they championed is too large and the project will have to be shelved. Or put a pause on a critical project because the application is approaching the hardcoded JS limit and another department shipped before you did.
Hardcoded limits are the first tool most people reach for, but they fall apart completely when you have multiple teams working on a product, and when real world deadlines kick in. It's like the corporate IT approach to solving problems — people can't break things if you lock everything down. But you will make them miserable and stop them doing their job.
Firstly: Too bad. The dysfunctional practices of corporate software development doesn't override people's right not to have their own computer's performance trashed by shitty websites. It's their right to run whatever browser they like, including one that doesn't allow slow, bloated and poorly engineered software to run, no matter how hard it makes life for the marketing departments of the world.
Secondly: For decades computers operated with extreme limits on their available memory and their processing capacity, relative to today's computers. Despite this, people managed to write software, even including companies with marketing departments and idiot VPs. It might take these people a while to accept that they can no insist on pushing whatever garbage they want, because the cost is borne entirely by the end user, but eventually they will. Or they won't, and these dysfunctional companies will die out. Either way, users win.
Try telling your marketing department that they can't integrate third party scripts through Google Tag Manager, or a VP that the SDK for that third party service they championed is too large and the project will have to be shelved. Or put a pause on a critical project because the application is approaching the hardcoded JS limit and another department shipped before you did.
Hardcoded limits are the first tool most people reach for, but they fall apart completely when you have multiple teams working on a product, and when real world deadlines kick in. It's like the corporate IT approach to solving problems — people can't break things if you lock everything down. But you will make them miserable and stop them doing their job.