It was done to make the plane cheaper to produce while staying within the grandfathering envelope and not require pilot training. It was pure greed.
This is a non sequitur. By this logic, avoiding being greedy must involve making your product new from scratch and making it expensive.
No, you're committing reductio ad absurdum, except not to make a point about going too far. As an engineer myself, I think grandfathering and iterative improvement are perfectly valid, and it does NOT always make sense to start from a clean sheet. Adding functionality to an application with a quality codebase does not require clean-sheeting the whole program. However, over time as so many different programmers touch a system with a lack of coherent style and design patterns, it can become decoherrent and more than difficult to work on. At some point, especially with a small team, you reach a breaking point on features taking longer to produce while bug reports pile up from the depths of legacy Hell.
On one team, I had to upgrade 10 Java apps that had been built on Spring Boot 1.2.1 to Spring Boot 2 while also pulling them off Windows Server 2008 and moving them to CentOS. They had been coded by a team of external contractors who were no longer with the company and who had left no documentation whatsoever on the requirements or thought process behind each of them. Furthermore, I'm no expert on the build systems of Gradle and Maven. When you go to upgrade Spring Boot, you have to upgrade the build system versions. Okay, that's fine until your build properties files suddenly stop working because breaking changes were made to the syntax and semantics while the errors provide no assistance. So now I have to triage the build until it works, and suddenly I get tons of compiler errors because a bunch of WSDLs (SOAP API contracts which are completed at build time, nasty work) suddenly either didn't build or built in the wrong order. Now it's down the rabbit hole of sifting through documentation and Stack Overflow to figure out how to translate the old into the new, while of course ensuring no IP addresses or meaningful code names get passed along. Oh, and now I'm finding out which versions of the other 3rd party libraries work correctly with Spring Boot 2. Oh and now I need to also upgrade to Java 11 because Oracle's ending Java 8 support. Oh and while we're at it let's also change Java providers from Oracle to AdoptOpenJDK because Oracle now wants to charge you $25 per core per machine per year that you run a Java environment on. So now I need to change the PowerShell AND Bash scripts to handle the new generic Java path schemes so our SSL certificate renewal processes don't break and cause an outage at the worst possible time. Fan, bloody, tastic!
If I'd known how nasty the upgrade was going to be I would have just yanked down a Spring Starter project, watched a couple Youtube videos, and rebuilt the 10 applets from scratch in no time flat.
Boeing could have, given free reign, raised the height of the 737 MAX and told airlines to simply get more luggage equipment because that's the compromise to getting better fuel economy with no pilot training. Then the engines could be moved back, be made the same size as the A320NEO (making the MAX an even fiercer competitor), and MCAS is never even thought about.
So yes, Boeing got greedy while getting stuck between a rock and a hard place because of incompetent regulators who very easily could have compromised and accepted improvements on a grandfathered type so long as handling was the same and pilot training needs would be minimized. The problem with regulators is rigidity when it comes to these schemes, and it's just the completely wrong approach.