SHA-3 was released by NIST just over 4 years ago this week. In my experience it does not seem to be as widely used as I might have expected. I see SHA-2 and even SHA-1 more often. What are your opinions on why this is the case?:
First, you're taking the question backwards. Inertia is the default position. You shouldn't be looking for reasons not to switch, but for reasons to switch. If there are no strong reasons to switch, nobody will switch.

Security is not a reason. Between SHA-2 and SHA3, there is no reason to believe that one is more secure than the other. It isn't like when switching from MD5 to SHA-1 or from SHA-1 to SHA-2, where in each case the older function has structural weaknesses that did lead to attacks, and had a smaller output size that was starting to raise concerns over brute-force attacks. SHA-2 and SHA3 have the same sizes and no known structual weaknesses.

Performance is not a reason for most applications. Indeed, performance is a reason not to switch. SHA3 is slower than SHA-2 on a general-purpose processor. It was one of the slowest finalists of the SHA3 competition across various processors. This is not a big reason not to switch, because hashes are pretty much never a bottleneck, but it's certainly not an incentive to switch.

SHA3 does have a performance benefit, which is that it's cheap to implement in specialized hardware. It's very fast on a dedicated circuit. This is especially important for low-power devices: SHA3 costs fewer Joules per byte than SHA-2 (or any other SHA3 finalist) when implemented in hardware. So IoT may drive the adoption of SHA3. However, hardware design takes time, and hardware designers are conservative (you can't fix bugs in hardware), so this won't happen any time soon. Furthermore, a hardware implementation of SHA3 uses more gates than SHA-2, so it costs more to build a SHA3 device, even if it costs less to use afterwards, therefore there isn't a clear cost incentive to switch even when a low power requirement is critical.

SHA3 also has a versatility benefit. The same core primitive (the Keccak sponge) can not only be used as a hash, but also as a MAC (KMAC, at lower cost than HMAC), as a key derivation function (SHAKE with a partially-secret input, at a lower cost than constructions such as HKDF), etc. It's not that SHA3 can do things that nobody else can do, but it can do things that otherwise require more complex combinations of primitives. That's an incentive to switch, but only in circumstances where 1. you need those extra things and 2. it is a problem to combine more code. Again, IoT (which wants low-cost, low-power devices) may look towards SHA3, but only once protocols that use more than SHA3's hash functionality are defined and start being deployed.

Coming back to security, a benefit of SHA3 is that it's very different from SHA-2. Indeed this is one of the main reasons it was chosen over other SHA3 proposals: since its construction is different, if a new class of attacks breaks SHA-2, it's unlikely to apply to SHA3, and vice versa. The security benefit would not be in switching to SHA3, but in deploying software and protocols that support both, so that if a weakness is found in SHA-2, the world can quickly and cheaply transition to SHA3.
