They are not entirely broken

While the keccak core as used in SHAKE/SHA-3 is very good, it hasn't received anywhere near the amount of analysis that the MD4 through SHA-2 constructions have. I am not a cryptographer, but I trust that the weaknesses have been resolved. In particular, the construction of SHA-2 is very different from that of MD4, MD5, and SHA-1. The similarities it shares (unbalanced feistel-like construction, davies-meyer compression function, merkle-damgaard padding) are rather superficial. The germane difference is that the older designs used a single heterogeneous non-linear function that changed based on the iteration, whereas SHA-2 uses all four functions (choice, majority, sum 1, sum 2) on each iteration.

> though they can be defended against in older hash functions by prepending the total length to the message before calculating the message digest

The best way to mitigate it would be to use SHA-512/256, I'd think. Then the hash itself becomes resistant to the attacks and there is no need to change the way the hash is used to work around its own limitations. As an added bonus, on 64-bit machines, SHA-512 is faster than SHA-256 so SHA-512/256 is a more efficient way to get a 256 bit digest than SHA-256 itself.

The primary reason that I am not a fan of SHA-3 is that it is designed to be extremely fast in hardware and not a general-purpose SHA-2 replacement. Its heavy use of bitwise transpositions makes it very efficient in silicon but less efficient in software. This makes it quite bad for slow KDFs because it gives an ASIC an inherent advantage (yes we should all be using a memory hard KDF, but non-memory hard KDFs will be around for a long time). SHA-2 on the other hand is optimized for 32/64 bit operations in software, and efficient silicon implementations are an afterthought.