How can that signal anything other than improper planning. You prefer a changing codebase over something that has evolved and is being tested over a long period of time?

Yes but can you plan anything properly in advance? How many unknown unknowns aren't being accounted for? Maybe it's best to plan for improper planning. What to do when (not if) critical decisions start falling apart?

It can also signal very good planning. If a program is properly specified and all the business logic correct then implementation language is basically as afterthought.

I'm reminded of the software for the Gemini spacecraft. Does it still exist? We don't have any assembly or machine code. But much like today in the '60s the designers of the flight software, considered the assembly output to be an intermediate stage - a kind of temporary mapping from the real program. The real program was designed in "Math Flow 7" - a visual flowchart language for expressing logic. We still have the charts. Does that mean we still have the software? Is the set of charts the software?

This is equivalent to arguing that tech debt signals poor planning

I would much prefer it to be easy to change a codebase and for people to make lots of changes to their codebase than for people to stick with whatever they built up front

Yes, and, many many billions (trillions?) of dollars have been lost because the programming language couldn't be changed. Both things can be true.

New languages do in fact come out, and old languages get better, and old codebases are thing some people have to maintain.