なんで「技術的負債」だったのか？
コストを掛けて（形而上的関数型なんてちゃちなものでは無く、金や地位や好ましく思えるパートナーやの提供で）、技術者としての背乗りに成功したとしましょう。
それだけのコストを掛けるとなると、乗っ取る先のシステムは、それなりに成功したエンタープライズ分野と言えるものだと思いますが、
- その様な、常時稼働を要求されるシステムは、常に、全ての部分で、因果を仕切り切る事が必須
だと思います。しかしコストを掛けて背乗りした人間にしてみれば、
- 毎回の調査分析（因果推論）など、負債では無いか
と見えても不思議では有りません。
また、技術的負債がなかなか消えない（永久に消えない）とするなら、それを毎回の調査分析（因果推論）の必要性が原因と出来るのでは無いでしょうか？
そしてそれはたとえgo言語で書いてあったとしても、kotlin言語で書いてあったとしても、もっと凄い（未知の）言語で書いてあったとしても、全く変わりは無いと思います。（形而上的関数型言語がこの世に顕現した場合は、別です。）
時期的考察
技術的負債という言葉が流行り出したのは、10年前より古いという事は無いと思います。もちろん、技術的な源流がそれより前から有ったなら、そうなのかも知れませんが、ジャーゴンとしては10年前程度で良い様に思います。
そして背乗りを企図して来る人間が、20年前程度からだったとするなら、背乗り後、そのシステムの完全掌握に10年掛かったとすると、辻褄が合います。
コストを掛けて乗っ取った人間にしてみれば、「こんなはずでは無かった」との感想を抱いても不思議では無く、
その思いが「負債」というネーミングになったとしてもうなずける所です。
本当に負債？
もしソフトウェアシステムが、外部の変化に対応すべきとするならば、その「負債」は永久に消えないでしょう。
それが本当に負債ならば、ですが。。。
特に現に動いているシステムだったとすると、その上での「こんなはずでは無かった」という感想は、負債では無く、調査分析（因果推論）の余地で有り、
進歩出来、外部の変化に対応出来る根拠となるべき余白で有る、と考える方が妥当に思えて、なりません。
結論
これからも「するべきだった事（調査分析（因果推論））」をしなかった事でプログラミングが嫌いになる人は存在し続けることでしょう。
