What Casey is making is more like a reference guide to "if you encountered a similar problem, here is how I worked through it". Hundreds of hours of live video content is good source material for resolving a certain kind of coding bottleneck where there are no standard solutions. But it does also mean that most people, looking to solve standard problems in standard ways, had their questions answered at the very beginning, and the stuff that he's implemented since then pushes at the boundaries of his own knowledge. He doesn't have an ideal lighting or physics solution that he can clearly articulate step by step, but he also doesn't want to cut it down and leave those things unaddressed for the sake of making a consumable tutorial. So a lot of these later videos are plodding forward, revising, doing something a little hacky, coming back to it to change the approach.

And I think that's valuable in a different sense - for people who want to pursue engine dev in depth, this is ideal content. They want to see that grind taking place and how someone with a lot of experience approaches things. What they should and shouldn't prioritize. It goes well outside of the usual bounds of "education", which tries to package up testable knowledge, and is more akin to seeing a top athlete's workout.

Casey asking "why wouldn't you use UE5" is not being combative or ranty: it's an honest ask of what problems need solving that aren't accommodated by what is clearly the technological leader in most of the traditional metrics(render perf, hardware usage, asset pipelines for high end 3D, source access), but are accommodated by Unity. It does show his blind spot, which is that he isn't able to envision the larger span of production metrics himself - team familiarity and inertia, particular pieces of tooling and UX, etc. - but he's also trying to fill in that blind spot here.