Personally I see a lot of value in backwards compatibility at Eclipse. Amongst others, the ResourcesPlugin is a very central API and its offered accessors to the workspace and friends are probably used by hundreds and thousands of plugins that are not under our control. Before moving code left and right, I would be really curious how a fully backwards compatible solution may look like.
Platform has policies and technical validation that ensure that backwards compatibility is enforced at API level: most APIs have tests that are contract/spec tests of the behavior, and there are a lot of tools to ensure API so linkage compatibility is not broken by inadvertence. Concretely, ResourcePlugin.getWorkspace() will never be removed.
If there are some tricky case you foresee about the upcoming refactoring which risk of breaking the current API contract, I suggest you capture them in some test case to integrate in the Platform test bench. In the best case, they'll be consensual and be merged to prevent this area from regressing in future refactorings; in the worst case, it's not clear the behavior being tested is a contract, but it brings the test brings the best possible material for discussing it.
What concerns me a little are the other exercises in that direction that did already land. I often read on bugzillas that class loading is dominating the entire activation and if a class is not loaded in context of plugin A, it will simply trigger the load in the context of a plugin B and there is no real gain in the total startup. After all, the code that is supposed to be executed must be loaded before it can run and before the workbench can appear.
Workbench is not the only consumer of the bundles. Many applications do run headless, repeatedly at build-time (API Tools for instance). So even if some refactorings do not impact workbench load, they can positively impact other use cases, that are also interesting.
Even if I will be perceived as the party pooper: Another concern of mine (there is always another concern...): Is this level of complexity that is inherent to any multi threaded solution for bundle activation and class loading worth the few milliseconds that can be shaved.
I looked at a few reviews on the matter of workspace initialization, and my impression is that it depends: in some cases, refactorings to use an OSGi service do not increase complexity, they sometimes happen to better separate concerns and thus improve maintainability/simplicity. But sometimes, it's indeed slightly more complex.
I have the impression those are similar to any change and should be treated individually like we do for all other changes, as there is not clear sign that things get systematically simpler/harder, better/worse,... when using services.
But in the end, I'm not a committer on the platform and only a consumer that tries to maintain a complex framework across various versions of Eclipse in a backward- and forward-compatible way. In the end I can only voice my opinion and try to understand the solution such that I know how to best use it such that the code is still fine with Eclipse 4.8, 4.20, and all versions inbetween.
Platform usually try to capture new patterns in migration guide and documentation. But for sure, if you want to still write code that targets Eclipse 4.8, you won't be able to use newer APIs and patterns, eg your plugin will keep calling ResourcePlugin.getWorkspace early in Activator and Eclipse Workbench will not start faster when your plugin is installed. But as long as you stick to 4.8 and verify you don't rely on APIs that don't get deprecated/removed, it should work with 4.20 even if some refactorings about internal Activator have been happening; 4.20 should not work worse than 4.8.
