Being good at a thing and explaining it well are different skills. Part of the problem is that you have to empathize with your audience when explaining. It's not sufficient to break a problem down into its essence; its "essence" varies depending on who you're talking to.

An example from something I've had to iterate on: When explaining an event loop multiprocessing runtime sort of thing, I eventually found I had to hand-wave "and your CPU hates that" to establish an appropriate premise to the problem and solution (referring to item-by-item dynamic dispatch with a large number of task types as the specific demon which needed to be slain while discussing that subset of the design). People in the know didn't need more understanding. People not in the know were happy to brush their lack of microarchitectural understanding under the rug. With that premise, both crowds were able to understand what followed.

That wasn't my first attempt. I have a bad habit of trying to explain those missing details as well, especially when it's clear the listener doesn't know them yet -- trying to get them into a position where they could've built the thing themselves -- but that only lands well with like 1-5% of people I've met.

Critically, agreeing with you, that's a communication failure, not an engineering failure. I understood the problem just as well in both cases; I just didn't understand the full extent of the people problem.