That post was made in mid 2018, and BLAKE3 wasn't published until late 2019; I don't think it was considered.
SHA256 with hardware acceleration might be competitive with BLAKE2, but not with BLAKE3 (performance graph at https://raw.githubusercontent.com/BLAKE3-team/BLAKE3/master/... ). BLAKE3 is also capable of being heavily parallelized without changing its output, as well as quickly updated without rehashing entire objects (if you keep some partial hashes around). Overall, it'd be quite desirable.
Hopefully all the work to abstract the choice of hash algorithm will make it relatively straightforward to prototype the use of other hashes.
They did consider and ruled out KangarooTwelve, which has basically the same properties of BLAKE3 while being derived from Keccak (therefore, with more chances of ending up as a US federal standard).
I'd agree that it roughly does. It's omitted from that chart mainly because it's not very common, but also because the input length measured there would makes K12's throughout appear lower than it should. The BLAKE3 paper contains more detailed graphs across a spectrum of input lengths.
I think that part of the performance gain of BLAKE3 is due to the fact that it uses a Merkle tree or something. SHA-3 has ParallelHash. One could use that with KangarooTwelve potentially.
I would really like an AES-based hash function as AES-NI is much faster compared to chacha20. There was a function called echo that worked like that during the SHA-3 competition but it was dropped before the final round.
It does; I've encountered some cases (ingesting large amounts of data into git) where the limiting factor on performance is a combination of SHA-1 and DEFLATE.
