The problem you described actually happened with Firefox and Firefox forks not too long ago. Mozilla kicked out all traditional Firefox add-ons from their repository to "replace" them (note: they didn't actually replace the vast majority) with chrome style webextensions. Firefox forks were forced to implement and run their own add-on hosting system and API, and navigate the complex legal waters of re-hosting the add-ons if they wished to continue having access. One notable example of this is the Pale Moon browser. But it all turned out all right. The PM add-on "store" works great and is reliable.
It's not beyond the capabilities of efforts like Vivaldi or Brave to do the same as the Pale Moon team.
And how many add-ons are updated and maintained specifically for Pale Moon - especially compared to the number of add-ons for Firefox for which that is the case?
Because that is the danger for the Chromium forks too - that nobody will bother with their forked store.
Ironically Firefox killed their extension API to be compatible with Chrome's extensions. Now they probably don't want to be compatible with the new Chrome API.
As well as to expose a stable extension API (no more XUL extensions breaking randomly on every browser update) and to enforce any sort of security boundary/permissions system.
Its sad to lose DownThemAll and the plethora of othwr XUL extensions, but having performant multicore support is critical given the shift to having many cores (as single thread performance improvements become uncommon).
I recently used the webRequest API in Firefox and it is already more robust than the Chrome equivalent. For example, you can write stream filters to process request responses. No so in Chrome, where you have no such capability.
It's not beyond the capabilities of efforts like Vivaldi or Brave to do the same as the Pale Moon team.