It's a trade off like everything. More DTOs means more mapping, more coming up with names, more files etc. There's definitely a middle ground.
You can (should) also apply it selectively. Eg for auth, I'd never want a single UserDTO used for creating and displaying a user - creating a user requires a password, a field you don't want when retrieving a user, to avoid mistakes.
I know DDD advocates would say that you're then not being true to DDD, but yes that's business. It's very very hard to get everyone to agree with the reduced velocity of 100% adherence to DDD for an extended period. In my experience it starts off as "this is great" then people start hate reviewing PRs for simple changes that have 28 new files (particularly in Java) and they quietly moan to the boss about being slowed down by DDD
I basically agree with this. Extra objects do carry costs. That said, usually the extra objects are necessary to make your code conform to reality. N things with N names in N files definitely carries overhead, but if the alternative is N things with 1 name in 1 file, and programmers carrying the complexity in their heads (or the complexity being a bunch of spaghetti in the one file), I'll happily accept the N - N - N side of the tradeoff.