This question already has an answer here:
I read a blog article which discussed SHA-3. I noticed it mention that security was often compromised in the name of speed (not always a bad thing, of course). It gave some examples:
What I'm saying is that although they care deeply about security, they are also looking for compromises to gain speed. This can be seen with the push for 0-RTT in TLS, but I believe we're seeing it here as well with a push for either KangarooTwelve (K12) or BLAKE2 instead of SHA-3/SHAKE and BLAKE (which are more secure versions of K12 and BLAKE2).
This is explicitly claiming that BLAKE is more secure than BLAKE2. I wasn't able to find anyone else claiming that, so I went to read the actual paper to see what changes it made to the original:
Fewer constants used. The original argument was that the constants improve diffusion.
Fewer rounds used (from 14 to 10 for 256-bit digests and from 16 to 12 for 512-bit digests).
Fancy features such as hash trees and personalization values added.
Some generic security trade-offs made (in regards to salt and IV processing).
Extensive speed and memory optimizations for implementations in software.
The first two points do not increase security at all, and arguably reduce security. Reducing the rounds was done because the best preimage attack was only found against a 2.5 round variant. This improves speed considerably at the expense of security (at least on a theoretical level). The reduced number of round constants reduce diffusion in the name of a lower ROM footprint.
It's possible that the author of the blog post mentioned simply read about it using fewer rounds and claimed the security was meaningfully reduced as a result, or it could be that it may have practical implications. My question is whether or not there is any concrete reason to consider BLAKE2 to be less secure than BLAKE and to use the latter instead for that reason (when speed is not an issue).