I think thinking of the "sunk cost" as being only or even primarily code is incomplete. It's internal expertise in that language, understanding of its strength

I think thinking of the "sunk cost" as being only or even primarily code is incomplete. It's internal expertise in that language, understanding of its strengths and weaknesses and how they fit into your business needs, custom tooling around dev, debugging & deployment, practice evaluating candidates for expertise in it, particular strengths of that language not guaranteed to be in a replacement, just all of the "unknown unknowns" that you now know through bitter experience. Surely there will still be a point where it's worth throwing all that out and starting fresh, but some of those are very hard to quantify or even see, when you have them, so the conservative choice is to stay put in the system that works.