Because presumably you don't always know the length of the data when you start with hashing. Like if you hash a file you're reading, it could get appended to while you're reading it. Or imagine hashing a video stream as you are recording it.

The solution newer algorithms seem to have settled on is to instead get fancier in the finalization step, for example by having internal state that doesn't make it into the final hash but would be required to compute the longer hash (just like using SHA512/256 to avoid length extension attacks).

The length may not be known ahead of time. Hashing algorithms generally work on streaming data. For example, suppose you wanted to hash compressed data while it's being compressed, you can't reliably predict the size of the compressed data.

The proper answer is to use something like SHA-3, which relies on an entirely different, simpler yet more powerful design. The underlying problem here is, conceptually, that together with the hash you release the entire state of the "hashing machine". SHA-3, to simplify a bit, truncates the output bitstring, and therefore does not release the entire state of the hashing machine.

Length extension attacks are in every crypto 101 class, everyone who designs crypto systems knows about them and acts accordingly. For example by using Galois field arithmetic to generate authentication codes, not hash functions (bonus: it is faster).

But then you down the rabbithole of UTF vs ascii byte length.

The OP advice is reasonable... just use HMAC. As far as I know it always available if hash is.

My doubt too. I understand what's happening but not why. :(