I can't judge the veracity of the history of hash functions, but the moment it starts talking about cryptography it goes completely off the rails: it seems to indicate that finite field exponentiation o'r high degree polynomials are used in cryptographic hash functions; they are emphatically not. It presents password hashing as just applying a suggest function to the password; in practice a KDF is used, which is a completely different design space (for a start, KDFs have a tweak parameter, usually called a salt in this context). Finally, there's a haven't reference to quantum computers breaking hash functions and needing post-quantum algorithms as a result. This does brush with reality in that Grover's algorithm does theoretically eat half the first preimage resistance security level of your hash function, but even SHA256 will require 2^128 iterations on a quantum computer, which will likely never be feasible. Worse, it doesn't help at all in attacks against second perimeter resistance or collision resistance.

Considering that everything I have personal knowledge of here is obviously bunk, best ignore the rest of it too

The right way to understand modern general-purpose cryptographic hash functions (like SHA2) is just to understand block ciphers. A hash function is a block cipher's permutation core, wired to a "compression" function (much simpler than compression as typically understood; somewhat analogous to the chaining CBC does) that feeds blocks through the same permutation continuously, scrambling state as it goes.

Everything gets tweaked differently because you have different constraints and parameters for a hash function than for a block cipher (though: there were SHA3 contestants that used Rijndael/AES for the core permutation, which is attractive because it has broad hardware support), but the core doodads are basically the same.

(And of course, you can run this argument in reverse and derive a cipher from a hash function trivially. That's how Chapoly happened.)