I like BLAKE3 just fine. Nobody's really going to ding you for using it (or SHA3 for that matter). But it would not be sound practice to tear SHA2 out of a system that was already using it.
Two other notes:
(1) The article explicitly recommends HMAC-SHA2, not SHA2 by itself.
(2) Where it does recommend SHA2 directly (for hashing, not authentication), it recommends 512/256, which is truncated and can't be length-extended.
The article references this as "YoloMAC" with a link to a pretty good Trail of Bits blogpost about it. But the TLDR is that just prepending the key to the message can lead to ambiguous encoding problems, so you still need to add extra complexity to your hand rolled keyed hash to handle things that the underlying hash primitive isn't going to protect you from on it's own. You're better off using a non-hand-rolled construction that protects against all the things including length extension.
Swapping out sha256 with something else when you would have had an extension attack means you're probably going to flub domain separation or miss committing to segment lengths or something else that is an inherent footgun that can't be misuse resistance your way out of but which harder to get right and more easily consequential than avoiding MD extensions.
Misuse resistance is important for sure, but the MD length extension is not in the same fragility class as stuff like 'relied on the caller to provide randomness for ECDSA'. And the hardware implementations of SHA256 have quite good energy efficiency and the algorithm overall has held up exceptionally well.