You're a 100% right with that example, I just think it's important to pry these apart as separate issues. The issues you faced should've been solved by a simple data transformation at the system boundary. "Don't let external data formats permeate through your codebase" is, to me at least, basic engineering intuition. There's no deeper meaning to be gleamed from that, the team lead displayed gross incompetence and now you have to clean up his mess.
On the other hand, these "clean architecture" blogs paint this ungrokkable colossus as a northstar -- they contrast it with issues like yours, and present this as the cure to every problem you've ever had in software. I just don't think that's true. None of these blogs ever highlight the loss of understanding. As you approach this style of engineering, you have so many layers, dependency injections and "oh and btw also this" style cross-cuts that no single use-case i.e. codepath can be understood by single person. You're just writing small units of code and hurling them at the codebase, hoping they enter the black hole's orbit and do what you want them to. I like to think that's why Uncle Bob uses huge, unexplorable celestial bodies for book covers :)
P.S. as a counterpoint to your example, I work at a company that's infatuated with the idea of microservices, with little consideration of the tradeoffs involved. A while back I had to add a feature to a new microservice that had been a few months in production. After a couple of weeks of wading through the ports and adapters, DDD-inspired architecture, I realized two things: one, this "service" is just exposing CRUD operations on a single database table with zero business logic in the middle. And two, the Data/ORM adapter layer of the architecture does not work. The migrations are never executed, the DB entities are never mapped, and SQL queryies never fire. Looks like nobody used it since it was first deployed :)