I read a post once from another (claimed?) ex-employee who said that around 2009 or so, Opera wasn't doing so great and they laid off a dev or two and then after they recovered half a year later, they never re-hired to fill the gap. The poster accounted the technical falling behind to that layoff. Do you share this impression?
As for me, I still use Opera 12 almost on a daily basis and the main issue I have is not broken websites but inaccessible websites because of HTTPS and Opera not supporting enough recent ciphers. The second most frustrating thing is that the JS engine shows its age performance-wise; pages that make heavy use of it for all kinds of dynamic shenanigans get rather sluggish. So my uneducated guess from these observations is that it should have been possible to keep up if they'd wanted to. It's probably that management simply thought using an engine that someone else maintains for them makes it possible to cut down on devs even more. But that part might just be my make-believe world...
It seems to me to be overly simplisitc to take a specific event and say "that's the decisive moment where it all went wrong".
Technically Presto had some unique features; for example the inturruptable script engine allowed the browser to feel performant and responsive without having to heavily invest in parallelism via multiple threads or processes. But it also had some architectural differences to other browsers, and never had the market clout to ensure that the Opera-unique features were reflected in platform features and so had to be implemented by the competition, or even to ensure that features that were hard/impossible to implement in Presto did not become required for web-compatibility. For example Presto was unable to implement beforeUnload without a significant rewite of the core document loading pipeline, but that omission from Presto wasn't enough to prevent sites depending on it when it worked in Gecko/WebKit/Trident. Similarly a lot of effort would have ben required to port Presto to multiple processess (similar to the multi-year "e10s" effort for Gecko).
Presto was also highly optimised for memory consumption and so was ideal for running in resource constraimed environments like early smartphones and games consoles. But I think the launch of the iPhone and Mobile Safari changed consumer expectations for the web experience on mobile and Opera didn't manage to respond in an effective way. I have no idea what the optimal response would have been, but if Presto could have achieved double-digit marketshare on high-end mobiles (as opposed to low-end devices running Mini), we might have avoided many of the compat issues that currently affect the mobile web.
Organisationally I think there were other issues; I already spoke about the focus on the particular use case of making a highly integrated, highly configurable, desktop browser product, which doesn't look much like the more successful mass-market browsers today. I think later there were other problems, but I was far away from the executive decision making, so maybe I'm not best placed to comment on what the actual company goal was.
As for me, I still use Opera 12 almost on a daily basis and the main issue I have is not broken websites but inaccessible websites because of HTTPS and Opera not supporting enough recent ciphers. The second most frustrating thing is that the JS engine shows its age performance-wise; pages that make heavy use of it for all kinds of dynamic shenanigans get rather sluggish. So my uneducated guess from these observations is that it should have been possible to keep up if they'd wanted to. It's probably that management simply thought using an engine that someone else maintains for them makes it possible to cut down on devs even more. But that part might just be my make-believe world...