Intent to Deprecate and Remove offscreenBuffering (2014)
groups.google.com
groups.google.com
The very premise of the deprecation and removal is that any code-base that uses that functionality is being constantly maintained and can be updated. That is a major misunderstanding that in the 'web' development world has become the norm due to 'DevOps', Continuous Integration, Continuous Testing.
There are many codebases out there that achieved their objectives, are finished, and are effectively unmaintained since they work as designed. When the functionality they use is removed they fail and the end-user loses out.
This is always going to be a major problem for historians, historical web-site and code archives that have active code (not just passive HTML/CSS). The problem we have is that with deprecations and removals of functionality that was previously recommended and/or 'best practice' our ability to maintain digital history is being chipped away.
Historically, we've already lost the ability to easily use Adobe Flash (good from a security perspective but not so much from a historical perspective) and Java applets (still many 'enterprise' devices rely on them) and all those web-sites that relied on Internet Explorer specific features.
For each codebase we now have to figure out which specific tooling and versions are required and try to re-acquire them. Not excessively difficult for open-source tooling but challenging for closed-source and proprietary tooling. Another related issue building up is the switch to 64-bit and the subsequent bit-rot of 32-bit support.
It feels like the horizon to failure of a completed "web" codebase is less than 10 years.
I would think that a prepackaged, heavily sandboxed VM with the appropriate configuration and software could be provided alongside the artefact of interest, much like using DosBox to play old games.
This would be inconvenient, but in cases such as Flash it should not be possible to run the vulnerable software without being forced to acknowledge the inherent security risks (especially if the container interacts with the internet).
Otherwise why put in more work into removing something than its presense will ever generate.
Like when Python removed support for Windows 7 for no good reason at all but it being past LTS. But there was a submit ...
The things that are barely used/almost unused are the things that often end up the least tested or looked at.
Depending on how complex they are, and what they do, this is a recipe for bugs/security issues.
When you have thousands of these things, not removing them over time is a great way to end up with a huge mess.
On the other side, as you say, removing any of them rarely benefits users directly (except in some individually minuscule way like binary size).
What seems to happen here strikes me as a reasonable balance - people try to trade off the complexity of the feature vs its use, and wait for it to become unused enough that it might be worth removing.
As you can see, here they decided it wasn't worth it, and it's still there today.