While I share your general notion that companies better adjust to the process of SAP, I still want to comment on the "impossible to upgrade" part, as that is simply not true.
First off, in SAP speech, "customization" is the act of simply adjusting the vast configuration options. This does not affect your upgrade possibilities at all. Even if you go so far as to add custom programming, as long as you (lowest complexity) just have programmed additional "transactions"/reports, you will usually not run into a problem.
The system also provides various mechanisms to extend standard transactions via hooks or to extend standard tables and still be able to upgrade without additional effort. I was actually astonished how much customization SAP allows in that regard while still staying compatible to the standard codebase - probably one of the reasons everything is so damn resource hungry, because there are multiple layers of indirection at work to allow this. From a development point of view, the major annoyance here is there are so many different options to extend stuff from different decades, so for some use cases you will use BADIs (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...), for others "exits" (https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=1...) and it is all a pain to lookup and locate.
The one thing which will get you into trouble is if you manually patch standard programs - which you are able to, the whole business logic comes with sourcecode - and which is usually not necessary.