Completely disagree - convex collision detection is a neatly solved problem. SAT [0] is implementable in a couple of hours, and GJK [1] is a really neat algorithm that takes a ltitle more than SAT to implement. For optimising collision detection there's some spatial partitioning [2] algorithms that work really well.
The gnarly stuff comes in when you're trying to figure out contact points and impulse responses and apply them without blowing everything up. I've written some of this stuff for a few games now, and the resources below have stood the test of time IMO
Well yeah, people often assume that because they know how to tell if two shapes are currently intersecting, they've solved collision detection...and then their games turn out to have a bunch of detection-related bugs and glitches. Most notoriously, lots of homebrewed physics libraries suffer badly from tunnelling (i.e. when one or both bodies are moving so fast that they completely pass through another before the next time collision is naively checked, and so the checker fails to detect a collision at all).
And on top of that there is more to collision detection than just code IMO - setting up hitboxes that both feel right for the player and aren't visually glitchy is not as straightforward as it might seem, especially with 3D.
(Also, figuring out contact points is part of competently implemented collision detection.)
The gnarly stuff comes in when you're trying to figure out contact points and impulse responses and apply them without blowing everything up. I've written some of this stuff for a few games now, and the resources below have stood the test of time IMO
[0] https://dyn4j.org/2010/01/sat/ [1] https://realtimecollisiondetection.net/pubs/SIGGRAPH04_Erics... [2] https://allenchou.net/2013/12/game-physics-broadphase/