Someone will say "false dichotomy", to which I say, "maybe".
Undocumented code and decisions are just a more slowly accumulating cost, it is no less costly than bad or failing code.
This is a reason I love having outspoken and extroverted devs. The guys who love to talk so much that they will explain in extreme detail and at length.
I was reading through an old bug yesterday, and the guy who had done some work in that area had left a 5 paragraph explanation of what had gone wrong, what he thought may have caused it and some things he was planning on doing. Having that written down was invaluable when I got to the thing a year later.
Process rigour is not the goal. Communicating what is strange and different is. If you have guys who do that naturally, great. If not, you need some process.
In my experience, the devs that talk the most, know the least about how things actually work. They churn off trying to explain something and are either subtly or blatantly wrong, and you've got to reel them in before they get down the rabbit hole and misrepresent reality too badly. It can be catastrophic if they are interfacing with management or customers.
It seems to be a manifestation of the classic "baffle them with bullshit" strategy for dealing with ignorance or incompetence.
Coming up with innovative solutions to complex technical problems requires you to be in the weeds, and think non-linearly (e.g. using intuition); while communication requires abstraction to (preferably) only the most important elements, and linear composition of the ideas into speech or text.