So you don’t go to “modern” sites, then. Right now, there’s not a good story for sites with script-based functionality unless your rewrite it into SPFx. Depending on the requirements, “modern” is not always a good answer. Some one-off stuff should simply stay “classic”.

You’d need to rewrite functionality you’d built using any other development model on premises, as well. In other words, the fact that it’s script isn’t the problem.

The world changes, and as people who build on or support SharePoint, we need to “tend the garden”. If the IT folks had been in collaboration with the people who added those scripts, they would be known and inventoried for potential upgrade issues along the way. Blaming script for poor governance choices makes no sense.

Every upgrade I’ve been through has been stalled by the full trust code. Basically, if there is code in the mix, there’s work to do during an upgrade. Upgrades are an excellent time to reconsider what’s there, how it works, whether it’s still useful, whether it can be re-implemented using new platform capabilities rather than customization, etc. In other words, not a technical upgrade, but a transformation (or at least isomorphic) one.