The every day practice of software engineering has little to do with the academic discipline of computer science. What makes a good software engineer is not usually the same thing that makes a good CS major
Sure, but basic CS knowledge is an expectation in much of the software field (albeit less since the mid-2010's javascript boom). A lot of companies aren't going to hire you if you don't know the basics of data structures and algorithms
but then you wind up with an entire repo, or an entire engineering team utterly hobbled by a lack of expressive typing (or advanced concepts generally) and debased by the inelegance of basic bitch programming.
Disclaimer: I'm not the OP, and there are certainly places where using recursive type definitions is justified.
My interpretation of OP's point is that excessive complexity can be a "code smell" on its own. You want to use the solution to match the complexity of the job and both the team that is building it and the one that is likely to maintain it.
As amused as I am by the idea of a dev team being debased by the inelegance of basic bitch programming, the daily reality of the majority of software development in industry is "basic bitch" teams working on "basic bitch" problems. I would argue this is a significant reason why software development roles are so much at risk of being replaced by AI.
To me, it's similar to the choice one has as they improve their vocabulary. Knowing and using more esoteric words might allow adding nuance to ideas, but it also risks excluding others from understanding them or more wastefully can be used as intelligence signalling more than useful communication.
tldr: Complexity is important when it's required, but possibly detrimental when it's not.