You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.
If you're building something with specifications, then what are we even talking about? You know what you need to build so just build that.
But this thread is about what to do when you don't know. "Start the simplest way" is not always the right answer, because you have some information about what you plan or want or hope to build, so you can use that information. Not everything is a set of hyperlinked webpages, and you often know that right away, even when you don't have many details sorted out at all.
I'm not suggesting building a complex system from scratch. I'm suggesting building systems using tools designed to support the kind of system you're building.
Do you think your quote is true in all cases? Or are you implying that choosing to build using a framework implies building a complex system frame scratch?
Consider a different kind of system. Does every triple-A video game evolve from a simple framework-free implementation, or do most of them choose a graphics engine to build on top of? If a game studio chooses Unity from the start, for instance, is it building a complex system that won't work?
How is it any different to choose a web application framework from the start when building a web application?
You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.
Replacing non-framework JS with a framework is very hard. Replacing static HTML+CSS with React is much more doable, as it isn’t too hard to transform HTML to JSX.
Yes but if it turns out that you really are building an application, but you didn't think you were up front, it is likely that you started to add "just a little bit of js here and there", because after all each little thing you're doing is not that hard and it feels silly to block any one of those little things on "let's add a framework now". So then you find that you have a "non-framework JS" application that is hard to migrate. That's how path dependency works.
It's true that there is path dependency in the other direction. You implement a framework up front, but then it turns out you're making something too simple for that to really be worthwhile. But very similarly, no individual thing you're doing is a forcing function to simplify things, so you keep doing your simple thing with an overly complex tool.
It always strikes me that people want there to be one right answer for how to start a project, either always choose a framework up front, or never do that. But in my view it's just not that easy, you have to think about what you're doing and make the right decision for that thing.
A sibling comment to yours described it very well.
There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.