TDD tends to result in an encrustation of overly-specific unit tests that can make it harder to rethink a design as you go. It's a valuable technique, but can be counterproductive if over-applied unthinkingly. I've worked in more than one dev team that has imposed TTD-all-the-things policies they've had to retract.

Clean architecture as a goal is, of course, uncomplicated. It being a good thing is assumed in the term "clean". However, it is often only one of a set of competing goals and in practice sometimes genuinely has to be sacrificed in favour of hitting a deadline. Spending a year designing a beautiful cross-asset trading application for a new hedge fund is not much point if, in the meantime, the hedge fund goes bust because it can't trade.

These are both trade-offs. TDD reduces flexibility (there are purists who will say you're doing it wrong if that's the case, but in that case pretty much everyone does do it wrong and that in itself needs to be accounted for / traded off). Clean architecture can require more time/resources than a "dirtier" approach to achieve a specific short term goal, and that short term goal can genuinely be more important.

I'm not arguing against either, of course. They are both important and you should learn them. But an experienced developer learns that everything is a trade off.