Figma solved online tooling, collaboration, interaction protoyping, design systems, and stakeholder review with a single product. Their renderer can handle hundreds of frames in the same screen with no performance degradation.
Meanwhile Adobe continues to struggle putting together version of photoshop or lightroom on a tablet that people like.
On the other hand you have a Figma, product-led, figuring out what's best for users, and kicking ass with a web-based solution that IS what designers/devs need. Legends!
I'm sure there's more to it than this, but Figma started with a clean slate. Having a legacy codebase means a few things, and one that doesn't get talked about very often is that there is a lot of pressure to re-use code even if it would be more difficult than a re-implementation.
I've worked on legacy codebases, and it goes something like: you start working on a new feature. You realize you need to implement some extra detail you didn't think of. You mention this in standup, and your manager says something like, "oh, no problem, Steve implemented a function that does that back in '97. You should use that because the old code already handles all these edge cases." So then you spend the next 2-3 sprints struggling to get Steve's code working, because his code and your code both made some assumptions about the data model that are incompatible. It doesn't really help that Steve's code has some subtle reliance on global state, so you have to worry about saving that global state, changing it, calling Steve's code, restoring the saved state, all while praying to various gods that it doesn't break anything on another thread you didn't know about.
Or it would have taken just a couple of days to reimplement it in a way that already plays ball with your data model. Sure, it's not DRY, but dogmatic DRY can be a big source of pain in legacy codebase.