When reading the post, I had the impression that OP has never worked on a large project and seen what it's like to iterate on an existing project to improve it incrementally by working on the critical questions that may only make small changes to the overall app / project. Instead they're always thinking about and working on the large decisions (that are more or less inconsequential in the big picture) that you need to make when starting a project from scratch. I saw one comment about "fear of missing out". I think it's more along the lines of "fear of making the wrong decision and not knowing how to fix it". "Fear of the unknown" maybe. I think it's a useful exercise to think about and work on your early-stage execution (ie. figuring out how you'll prep things for a project, and learning about and understanding the implications of those decisions), but without any experience executing on the later stages of a project, it won't do any good.
There are generally alot of questions that need to be answered early on in a project, but once you've committed you just need to be confident that your skills to architect the project will be solid enough that they will keep you out of trouble, and the code will be modular enough that if you do spot big mistakes you can easily fix them within the existing architecture, avoiding the need for a complete (or large-scale) rewrite.
No, that is not the case. I've been a developer for nearly 20 years. I have a number of LOB applications under my belt that took years to develop. I have seen it all, but the last two years it's been a struggle.
I agree that it may have to do something with the isolation of freelancing on remote projects via the web, the rapid changes in development as a whole, and information overload.
I definitely agree that there are alot of things out there these days. It's difficult to keep up with those trends. But in my experience solid fundamentals translate well to any "shiny new object". The interfaces are different, and sometimes there's something really innovative about new approaches.
IMO in order to maintain a sanity about it all, you really need to dig into "what is this shiny object really accomplishing". This can help change one's perspective from "I need to learn it all to stay on top of new trends", to the realization that "There are really only a handful of truly innovative things happening behind all the shiny objects".
There are generally alot of questions that need to be answered early on in a project, but once you've committed you just need to be confident that your skills to architect the project will be solid enough that they will keep you out of trouble, and the code will be modular enough that if you do spot big mistakes you can easily fix them within the existing architecture, avoiding the need for a complete (or large-scale) rewrite.