"Changing the core" isn't generally any more encouraged by either system, if it doesn't result in marketable features.
The idea of the "complete overhaul" is something engineers love to dream about, business managers hate to do and end users generally just don't care that much about. That's why they happen so seldom - and usually only if the existing package is a pile of unmaintainable crap.
The shrink-wrap model encourages chasing adding more bullet points to the outside of the new box over actually improving the day-to-day user experience. The service model encourages making your actual customers happy with their product AFTER the purchase, so they keep buying.
The whole concept of a large, up-front fee is driven by traditional mass-media marketing strategy: spend a bunch of money making something sound really great to buy, sell it for a bunch of money up front so you can get a return on your advertising spend. Don't worry about what happens after that.
"I don't understand, what is the problem with that?"
The problem with that is if there is some small feature change that would really improve the current product (say supporting an additional new file format on import) there is little reason for the maker to add it to the old release. Instead, they lump it in with the new version and hope it forces you to buy a whole new license. So a feature that might only add a small marginal cost but would make current users happy for longer doesn't get released to them.
Firstly I said nothing of "complete overhaul", core changes are for example, the internet moving to IPv6, OSes moving from 32-bit to 64-bit.
Anything that is constantly updated with anything more than bug-fixes will become "a pile of unmaintainable crap", or just obsolete if the core isn't changed. Core changes normally happen before that point though. That is if business managers' incentives aren't all wrong. An example of that fairly recently was twitteriffic for iOS, they felt it was heading towards being a pile of crap so they had to stop and go back to the core.(even though it meant unhappy current customers)
Users not caring about it unless it immediately comes with new features or at least all the old features is exactly my point! And if what the user is paying for is updates they are absolutely not going to accept losing any features(and not going to be happy with not updating since that is the whole reason that they are paying in your method). If the user owns a version and sees that the next version doesn't have features they need they'll stick with the old version until the new version has those features. In your model they have already paid for that update.
"So a feature that might only add a small marginal cost but would make current users happy"
Prices aren't just based on costs, they are usually(in the IT sector) based on how much more they "make users happy", in some cases they are almost entirely based on that, clothes, shoes and apple products being the most obvious examples. Which to repeat in another way is the problem with core updates in your system, they are high "cost" but they only prevent the programme from going to shit so they don't "make current users happy"(just prevent future unhappiness).
That's not to say that your model doesn't work in some cases, anti-virus programmes need constant updates but very seldom core changes.(although oddly enough at least for norton it's much cheaper to buy the newer version in amazon or a shop and get continued subscription that way then to update a subscription) And you mentioned GPS apps the same applies to them, no core changes needed.
Angry Birds on iOS is absolutely not a case of it though, you don't pay for new levels, new levels are free and are an example of the opposite of what you're saying happening, you pay upfront and they have continued adding levels way beyond a point where it would have been reasonable for them to make an Angry Birds 2 and putting the new levels in that. It is a special case but it is the traditional model just with a new attitude (on iOS, on android it's the ad revenue model which is different again).
The idea of the "complete overhaul" is something engineers love to dream about, business managers hate to do and end users generally just don't care that much about. That's why they happen so seldom - and usually only if the existing package is a pile of unmaintainable crap.
The shrink-wrap model encourages chasing adding more bullet points to the outside of the new box over actually improving the day-to-day user experience. The service model encourages making your actual customers happy with their product AFTER the purchase, so they keep buying.
The whole concept of a large, up-front fee is driven by traditional mass-media marketing strategy: spend a bunch of money making something sound really great to buy, sell it for a bunch of money up front so you can get a return on your advertising spend. Don't worry about what happens after that.
"I don't understand, what is the problem with that?"
The problem with that is if there is some small feature change that would really improve the current product (say supporting an additional new file format on import) there is little reason for the maker to add it to the old release. Instead, they lump it in with the new version and hope it forces you to buy a whole new license. So a feature that might only add a small marginal cost but would make current users happy for longer doesn't get released to them.