One wonders why all the UI issues weren't solved long ago. Good that they're fixing them now, but what were they waiting for to decide to do it? (Rendering performance is a separate topic, that's been waiting on rust/servo.)
The reason that Firefox switched to webextensions was in order to switch to a formal extension API that could be supported long term, instead of the old open integration API which made it difficult to readable without breaking all sorts of extensions.
There reason they adapted the web extension API that chrome uses, was because it largely made sense, was already pretty fleshed out and would allow extension writers that were already familiar with that to also target Firefox.
I don't think they've been "waiting" to solve the UI issues: it's been years of slowly deprecating old systems like XUL, and implementing new systems like e10s. That's been years of anger or at least angst for extension developers, as much backwards compatibility was broken one piece at a time.
The fruit after all that hard work is the new UI.
The truth is that they were in a dilemma situation where they had to choose between not killing all extensions or fixing performance by introducing a multiprocess architecture (which required breaking all extensions).
So, the first thing they did was to simply wait. The performance issues were not that bad yet, so it just didn't yet weigh up to kill all extensions.
Eventually they started work on the multiprocess architecture. That was around 2012, if I remember correctly. They've been doing that in the background without visible results for the public for a long time. It's considered the biggest architectural change that Firefox ever went through, so yeah, that just takes time. Cleaning up technical debt that Chrome never had.
And then they also figured, if they already break all extensions, they should also switch to a new extension API in the same breath (because the old one has had big problems for as long as its existed). So, then they implemented that, too, in the background, in parallel, just to be able to throw it all on the table one day, so that extension authors would only have to rewrite their stuff once.
Indeed, I'm one of the people who has suffered from losing legacy Firefox extensions (find me a substitute for LeechBlock, please!), but I can see how much of a burden it was for the developers to compete on performance and security, which I value more. I'm hopeful that Firefox will continue to add sane extension APIs to help close the gap with what was previously possible without regressing to the old quagmire. Fingers crossed, but they've done well delivering so far with 57.
I never said I agreed with it.
Having to break legacy extensions due to internal changes is understandable. It would have reduced stress for the users if the new API was shipped first, then the changes made and the old one broken, though. Heck, they even thought of it first and did that - you may remember Jetpack. It never picked up steam because the APIs were too limited and too many people ended up resorting to the old APIs, though. Even now with WebExtensions they're shipping lots of new API extensions want in the same release that drops support for the old ones…
Oh, and they had multiple breakages as more and more things went out of process, not one giant one. That's life, really; things take time to build. I believe part of the pushback is that people just finished porting to e10s only to find that their new code will need to be rewritten again for WebExtensions.