I work in embedded, and the place I work restructured to have a dedicated software group. They hired young software engineers and focused on getting people who are good programmers without really caring what they were good at. Most people ended up being web developers and liked webstack.
We were tasked with making a handheld air quality measurement device with a touch screen that could pair with a computer app that we would also write. Most people on the team knew webstack so we decided on a HTML/CSS/JavaScript +SQLite that would run in Electron Chromium on Linux on the physical device.
So what went wrong? Well, electron is bloated for embedded devices and the mid-tier processor we were using chugged so much that it would get hot. Hot enough to affect the temperature sensors at the top of the board and throw off the gas density measurements. Our MVP was nearly done when we discovered this problem.
We had two choices: throw out the hardware or throw out the software. We ended up throwing out the software and starting over (in Winforms + C# if anyone's curious). I and two others quit as a result. It is _really_ depressing redoing something you've already done in a different language.
If we picked the lighter weight framework from the start instead of picking the language most people knew, we wouldn't have lost a year of work.
The “only good answer” if there is just the one is that you should use whatever fits the requirements. If those requirements involve you getting to market as fast as possible in a highly generic domain (ie building a standard website) where the tools you know work just as well as others and you’re not worried about various other factors then sure, go with what you know and can churn out the fastest.
But though many projects may fit this mold they are by no means universal requirements, and your requirements may very well dictate the best path is for you learn new tech (for instance if you usually do .NET stuff but are building a a ML service on a device or something). Sometimes there are better ways to accomplish things than what you already know and you’ll indeed be better served by learning them. If you’re just a hammer looking at everything as a nail because you can bang on it the fastest you’ll stub your (and probably others’) thumbs one way or the other.
Not to mention learning new tech is often its own reward regardless of the much less certain fate of a given MVP. At the very least you'll have another tool in the toolkit to assess future project requirements, rather than blindly attacking everything w/ a hammer.
At least that's the value I'm getting out of everyone's answers that actually talk about their favourite stack (vs just saying "use what you want" etc)
Yet it never goes out of style, apparently.