Security is a concern for older platforms. Data is gaining ever more prominence and it only takes one breach and regulatory fine to wipe out any saving you may have made by not upgrading.
If it is possible to script an entire install of the legacy software so that you can spin up and environment in under 5 minutes then at least the stuff is maintainable. As far as I am aware it is possible to do this for SQL2005 and onwards.
The ability to make the legacy software testable is also something that enhances the maintainability and longevity of software. If the legacy software is well designed then automated testing is feasible. If your legacy software is a big ball of mud and has become legacy because no one dares to touch it then it is a ticking timebomb.
In terms of upping the cadence of SQL Server release cycles I think there needs to be a rethink on marketing vs technical release concerns. A major version every two years feels about right. Feature releases more frequently would be handy. Perhaps the licencing of the product should be geared around the expectation of 4 feature releases included in the licence. That gives the message to customers that they are getting value for money and that the platform that they have invested in is progressing forwards at a rate of knots. That should make the financial hit of upgrading to a major release much more palatable.
I would feel happy with a SQL2016R2, R3 and R4 followed by a big bang for SQL2018 or 2019.
I like the idea of including a few versions in the cost. In fact, I almost wish that were some sort of regulatory item, perhaps requiring backporting or upgrades since the idea of selling software that has issues, constantly releasing new versions but not necessarily fixing old ones, feels a bit like a scam.