Yep, agree entirely, although I wouldn't advocate mixing the two in a single application--mixing mechanisms is added cognitive overhead.

But again, JS is just a language, that happens to have an interface into a DOM (in some environments). It's not a framework that guides you in how to organize and architect an app.

It's possible to write maintainable, high-performance, complex apps using plain JS. Adding a few simple layers makes it a lot easier, though, and I'd argue that the current crop of client-side frameworks make it easier still. Simple apps == simple code. Complex apps == complex code, regardless of the tools used to create it. Underneath everything, after all, is still just plain JS.

Well then to return to your original point that redux/webpage/flux/blahblah are overkill and you shouldn't use them until you need them, you can make the same argument. They are more layers that guide you in "how to organize and architect an app." The tradeoff is that you get simpler code in exchange for more architectural overhead and a more complex build process.

I never said they were overkill (and I'd argue Redux or similar pattern is useful even for fairly simple apps).

For an app of any reasonable complexity you'll have "architectural overhead" whether or not you're using your architecture or someone else's. That's just a given. (And if you don't, you have more overhead trying to figure out what you were doing.)

More complex build process? Yep, if you're not writing all the code yourself, and you want to distribute a single file, and ES2015 (or other) transpilation, and minification, sure. But you can use all the libraries in question without much of a build process at all, just load 'em all up and use ES5.

Complex build processes are a result of wanting to distribute and write code in a certain way. They're not a requirement.