Spare more than a thought for contrib

"Drupal being the one-size-fits-all tool it keeps growing into, contrib will simply never keep up"

They will always be at least a little behind by nature. If drupal core is growing, contrib has to grow with it, and just as drupal core takes time, contrib has to take time too. You have to wait for drupal 8 before you have modules that are fully compatible with drupal 8 (although if you keep your module up to date with drual 8 dev as it moves along then you will need much less time investment come drupal 8 launch - that is at the expense of the time you spend keeping it up to date with dev, so you have to work out what is best for you as a contributor/maintainer of contrib modules).

Also, that fact that more and more of the larger building blocks, like fields & views, getting into core, plus we have some really flexible contrib modules like rules (which can replace the need for a bunch of little modules that do one small thing each), less and less contrib modules are actually having to be ported (I admit though there are still a lot that could/should be ported).

"The contrib and bespoke space moves because there is business in it, e.g. site building, Platform as a service (PaaS), local Drupal user groups"

Doesn't that cover everything? The "site building" part of that says (to me at least) that the contrib space moves because of site building, which is pretty much the only use of drupal contrib modules, so this site building item covers all modules. If there are modules not used in site building, why do they need to be ported?
The drupal user base is not made up of entirely non-developer types, which means that when developer types have a client that has a site that needs upgrading they include in the price of that upgrade the cost of porting the required modules (unless they can find a new or alternative module that can achieve the same results, in which case that module can replace the need for porting the other one). I understand that a lot of clients will not want to pay for such things, but you can bet that there are companies that are willing to pay for it that are using most of the more commonly used drupal modules.
(A lot of modules are also updated by loving contributors who aren't being paid, or drupal shops who choose to allocate some of their work hours to port modules that they maintain)

Also, it doesn't even have to be paying for a full module port. Maybe there is already a half done port or an almost complete port, and you just have to spend a little time to submit patches to fix those issues.
I would generally be submitting such patches quite regularly just as I go through my day to day work (which is being paid for by clients) and I'm sure a lot of other developers are the same.

If you are a non-developer and cannot find an alternative module to replace a non-upgraded one, and you really can't afford to pay someone to upgrade it for you, then unfortunately that's tough luck and you might have to wait to upgrade until someone else ports the modules you need. That is just the way of open source software (you could always use something proprietary in place of drupal, which will give you better backwards compatibility between releases, but it will be at the expense of something else, so you have to weigh that up).

There is also the fact that as much as we might want to, we cannot cater for completely non-technical users being able to do everything relating to their drupal site without help (paid or otherwise).
If you want to be able to use drupal completely for free and to not have to wait for others to port modules for you, fix bugs, add new features, etc. you have to learn drupal so you can do it yourself.
Just like if you want to service your own car so you don't have to go through a mechanic when you want bug fixed and new features added, you have to learn car mechanics (at least parts that are relevant to what you want to do - and their underlying components).
If you want it done fast, without having to learn, pay someone to do it
The same is true for pretty much anything in life, not just drupal and car mechanics.

(non-drupal-specific note from my inner cynic: I think maybe the world's population's sense of entitlement gets a little out of hand at times :))

Of course another option is also to review whether or not that module is even needed anymore. Often if you are upgrading an old site you might want to take that opportunity to make a few changes to the site for the better, which can mean removing un-needed or unused features or replacing them with slightly different features that are available in a different module that does exist for drupal 8.
Sometimes a little creative thinking can get you around the need to port an old module.

"because the only people committed to doing good things in contrib are those supported by crowdfunding (again, precious few) and new contributors wanting to garner attention (who simply will not keep doing it for too long)"

I don't really think this is true, and some contributors might also consider it a little insulting. - It is surprising how often you see insults thrown at people who are voluntarily allocating their own spare time to help others (often it is also helping themselves, but that is not the point), regardless of how much time that may be.
I will say though that the amount of time that these developers can allocate is possibly often less than the amount of time funded contributors can allocate.

"The only meaningful resolution I can think of to close the "chasm of forward compatibility" is to start by making it easier for maintainers to advertise and hand over projects where funding has shifted."

This is not a bad idea, although there are already ways to do this, like the "Development status" and "Maintenance status" fields on the project pages, and also the ability for maintainers to use the main text of the project page to advertise such things. Some maintainers already do this.
The problem is that probably any new system for this would still have the same weak link as the current system - It is up to the maintainer to set this information.

Another problem is that often people are willing to make a patch to fix something or port a module, but they don't actually want to be a long term maintainer of that module for potentially a number of reasons. Finding long term maintainers that have enough time to keep on top of everything is hard, we need more contrib developers.

"The upcoming "graduation" of Drupal 8 into the wider PHP community will have a significant impact as well. Drupal projects can then essentially share a much wider resource pool to build great websites. "

This is true. One thing to note though is that there is still a lot of drupal specific code too, so we will have a 3 basic groups of developers (I know I could split these up more): Those that are good at drupal, those that are good at non-drupal like OO PHP, Symphony, etc., and those that are good at both. The first 2 groups will both need to invest some time to get up to speed.

"The goal is not just to narrow the "chasm of forward compatibility", but to shorten it as well. Imagine how great it will be when we no longer have to learn new PHPTemplate quirks but just stick to Twig for many Drupal versions to come."

Is that really the goal? I thought the goal was to keep adding new things (and fixing old things) to make drupal better and keep it at the forefront of CMS solutions. We don't throw out everything every new release, for example the form api is relatively unchanged for a long time, so there are always features that remain with us for a few releases. It is just that new things come and old things go, which will always happen.
Drupal 8 is a massive change that brings great new things like twig that I think will be with us for a while, however I assume drupal 9, 10 and beyond will continue to bring more new things that will affect compatibility (maybe to a different extent), and those new things will be required for drupal to continue to evolve and remain such a great CMS.

I agree that the practice of "-dev is the only stable release we have" is very problematic, even outside the D8 discussion.
This is especially true for distribution development. I've spent a nice chunk of Commerce Kickstart development creating "please create a release" issues in various issue queues.
It is also not a matter of resources, just making sure the stable release is at least as stable as what was already committed and is a part of -dev.
So this is something that deserves a blog post of its own.

You said:
"Most core developers make a living from clients who can afford high-grade professional devs"
and:
"Put shortly, core developers make a living from in the main from larger clients"

One can't make this generalization. Core developers are an extremely diverse group. Myself, until a month ago, I worked in a part-time job for a small university, barely made a living wage, and simply contributed back to Drupal in my free time because it gave me the challenge and community I didn't get in my day job. Many core developers work for small shops, or don't work for Drupal shops at all. Some are stay-at-home moms or dads. Some are musicians, thespians, or students. Most of us started in our spare time, because of personal passion or interest.

I know that the comment above is a troll, but since it sometimes pops up as an actual opinion, I'll bite.
People should remember that Drupal doesn't owe them anything either.
Use D8, or use D7, or use Wordpress, or go have ice cream. It's all good.