If you are called in to rewrite the project, I would say this signals a successful project: it was built in whatever tech stack a midling engineering team had competency in, it originally worked well but started struggling with more scale/needs/updates, and it is still worth enough to invest in rewriting it.

Yes, you may not enjoy turning a legacy system that works into a nicely architected system, but the ones that get to that phase are clear successes IMO.

Contrast this with systems which had nice, clean, maintainable architecture from day one but bit the dust two years later.

The original article is a silly shill, as engineering managers have looked at economic cost of choosing a language and other technology since... forever.

And some of that "invisible" discussion happens visibly too (I've done that a number of times: "how do we keep our engineers motivated who want to explore a new hyped tech stack vs the cost of them being slower or leaving the company").

Yes.

And because time to first release is often the difference between prosper and fail

It is not enough to be the best. You need to be the first