You're probably confused by "SHA-512/256", which does not mean SHA-512 or 256, but rather a truncated version of SHA-512: https://en.wikipedia.org/wiki/SHA-2 in the third paragraph.
Truncated hash functions are not vulnerable to length-extension attacks.
Length-extension attacks are relevant when you design a MAC by passing a secret and then a message to a hash function, where only the message is known.
Truncating the hash (which is what SHA-512/256 and SHA-384 do to SHA-512) removes the ability to grab an existing hash H(k || m) (where k is unknown and m might be known) and append junk because a truncated hash does not contain sufficient information to recover the full state of the hash function in order to append new blocks.
Because 224 bits is considered the minimum safe output length for a general purpose hash function. So they'd be drop-in replacements but still wouldn't be safe. Safer than MD5/SHA1, but not actually safe.
So rather than push off getting people to make things actually safe by providing a footgun NIST just didn't do that.
Truncating a hash function to 224 bits put it at the 112-bit security level, which is roughly equivalent to 2048-bit RSA under today's understanding of the costs of distributed cracking attacks.
There are a lot of standards organizations all over the world with various recommendations. https://www.keylength.com collates quite a few of them. Pick the one most closely relevant for your jurisdiction.
Most of them recommend 2048-bit RSA as their minimum for asymmetric security, and AES-128 / SHA-256 as their minimum for symmetric security. This is a [112, 128]-bit security lower bound.
Truncating a hash to 160 bits yields 80-bit security, which is insufficient. 128 bits (64-bit security) is out of the question.