Particularly with the web though, you're very rarely completely locked into one front end technology. It's 100% reasonable to say "this particular complex interaction should use React" without needing to port the entire application. I'm sure even Photoshop and Figma could build their account management or settings pages with MPA if they wanted to - I don't use them and have no idea if they do, but "some parts of my application require complex tools" doesn't mean "all of my app requires complex tools"
Absolutely, but it's a matter of tradeoffs and where you place them. It's still plenty common to use an MPA framework like Rails or Django for the management or CMS portion of your solution, while using an SPA framework for your front presentation. It's much more acceptable to say "doing that for this staff workflow is hard to do with our stack" than "doing this for our customers is hard to do with our stack".
Sure! I think it's just a question of scale and knowing your problem. If it's "the entire customer-facing area needs a large amount of interactivity" then going with a SPA makes sense. If it's "this particular UI element on the customer app needs a large amount of interactivity", that's easy to build as an isolated component regardless of the technology of the rest of the app.
One thing that I'll always view as a smell though is "we don't need X now, but we might need X in the future, so we should adopt this more complex technology just in case". We've learned that lesson MANY times as developers, it's not any less true for front-end technologies.
