Question: Why are SHA3 algorithms considered more secure than their SHA2 counterparts? Surely in part, it is due to their resistance to length extension attacks. But specifically, when considering collision resistance they have the same O(n) attack times.

Is it because they are more resistant to preimage attacks?

Answer: 
This is more of an addendum to fgrieu's answer than an answer in itself, but 3 things stand out that *COULD* make SHA3 more secure than SHA2 from a design standpoint.

The first and most obvious is the state size, SHA3 is substantially larger at 1600 bits than even SHA512... at only 512 bits. SHA3 being a sponge function gets its security level from how much of that state size it keeps hidden from the final hash output, and that is one of the reasons it is immune to length extension attacks. SHA-512 and SHA-256 output their entire state, the rest of the SHA2 family truncates to the desired length. Having the entire state available can make certain attacks against block cipher based hashes like SHA2 easier, tough truncation may lead to other attacks.

The second may change over time, the security buffer, or how much of the full round count is not broken by the best attacks against the hash function. For collisions against SHA2 this is between 56% [(practical collisions for SHA-256)](https://eprint.iacr.org/2016/374) and 30% [(pseudocollision for SHA-256)](https://eprint.iacr.org/2011/037) but a whopping 79% for SHA3 [(practical 5 rounds collision)](https://eprint.iacr.org/2019/147)

And the final thing is more about the way the hash can be implemented in software, SHA3 on 64-bit platforms requires less code to implement, which means less code to possibly be implemented insecurely. It is also considered (by most people that I know) easier to read the SHA3 code, and the round constants can be generated algorithmically at runtime.

> 
> Why are SHA3 algorithms considered more secure than their SHA2 counterparts
> 
> 
> 

The SHA3 competition was created because of new attacks against MD5 and SHA-1, which created a perceived threat that future analysis of SHA2 that could lead to practical attacks. This has not come to pass, and SHA2 has stood its ground against cryptanalysis.

The SHA3 competition spawned many fantastic hash functions that were more functionally capable than SHA2, had better hardware performance, or had better performance to security ratios. But that does not mean that SHA3 is the de facto MORE secure hash function.. but it also does not mean that SHA2 is either. They are very different designs, and SHA3 is more capable, AND SHA3 has a potentially higher security buffer, but neither are broken (except for length extension attacks, but that was already known).
I know you already mentioned length extension attacks in your question, but I don't think the importance of that can be overstated in how SHA3 is *practically* more secure than SHA2 - especially whenever you'll be designing your own cryptographic protocols/systems on top of it. Thanks to length extension attacks, use of SHA2 may require active measures (e.g. HMAC) beyond the hash itself in order to use it safely, and *most people using it don't understand this*. Even if they do, the need occupies space in one's mental model that could be spent on more valuable things.

In addition, implementations of SHA2 may be subject to side channels that, in certain contexts, leak information about the data being hashed. This can be critical when the hash is used with key material, such as in HMAC or signatures. [This paper](https://eprint.iacr.org/2017/985.pdf) claims to successfully recover private keys from the (2017) WolfSSL implementation of Ed25519 using such a side channel. SHA3 by design does not invite side channel leaks.