Oh, yeah. I'm not prescriptive about never replatforming. You just shouldn't do it without a very compelling reason and a lot of consideration.
If you've got a dozen microservices written in a mix of ColdFusion, Salesforce, something Microsofty, and some other enterprise slow-and-expensive platform running on leased bare metal with a bunch of third-party licensed support software and you're burning tens of millions a year on that, and you can get a team to rewrite the thing on another stack--virtually _any_ other stack, so long as you go from a dozen vendors to fewer--you can probably justify allocating your entire engineering budget for a year or two just to stop the bleeding.
Twitter built their stack on Rails, ran into performance issues that they couldn't mitigate, and replatformed. That seems to have worked out for them.
Neither of those are most of us.
Sustainable computing, as you're alluding to, is a whole other discussion. It's one worth having, but I hope there's other solutions out there than "write software the 10x slower and harder way", because otherwise anyone who tries it will be beaten by a less principled competitor.
Short of implementing a Logan's Run-style system of government, the existence of individuals tends to get determined a couple decades before they'd be available for hiring as developers.
Maybe, but when your software is the piggiest of pig software then it should be called into question.
Unrelated to Gitlab, but to give an example of what I mean:
How many installations of Slack are there in the world, or Teams.
even with an extremely conservative estimate of 10 million; 10mb of ram and 5% of a CPU core has a measurable impact on the planet.
With such a wide distribution it's worth calling at performance of the platform, even if it's nice that Teams at least supports Linux...