I think it’s largely a mistake to attempt 1-to-1 code conversions. Directly copying architecture with only cosmetic language syntax changes is a PITA. The real value in rewrites comes from having a better understanding of the problem, not going for complete feature parity, and instead focusing on improving core functionality. The first time you write something, it’s not always as clear what that core functionality even is.
Mayyyybe you want to get to feature parity at some point, but there’s value in removing features that have proved troublesome and streamlining the feature set. If you can get away with it, it’s nice to enable some of the quirky compatibility features via plugins rather than keeping them in the core piece of software.
Anyway, this piece clearly had a specific experience in mind (perl to python, gtk-doc), and was using a conversion process based on the need for direct parity, so I would tend to agree with the author about the feeling of futility around that effort. Could a better gtk-doc be written by a person deeply experienced with it? Maybe. But it wouldn’t and shouldn’t look like a direct language port.
For really long-lived projects there’s a lot of inertia to overcome, which I suspect is why you don’t see higher levels of churn happening. Old projects have reached a level of stability, and are “good enough” to the point where it takes an enormous effort to push for change. That’s why US banks are still running on COBOL, for example.