I've always encouraged people to check out Jonathan Blow's talk on this topic ( https://youtu.be/JjDsP5n2kSM?t=817 ). He points out many reasons why this type of code would actually be the optimal version when weighing other factors.
Simple code is easy to write, maintain, and optimize later. Despite the code looking messy, I find it easy to understand and navigate.
I think I've watched that talk before. The starting point you linked to talks about when to do linear searches. Anyone with some experience knows that stuff. It's a good thing to tell undergrads in case they missed it, but Blow always acts like he's some rebel and conventional wisdom has it all wrong, which isn't really the case. Conventional wisdom says there's a place for linear searches (after all, lsearch()).
Anyway, he's just wrong about long functions being a-ok. I suspect he doesn't write many unit tests. This is the main benefit of separating the code into smaller functions. You can test each. Even if it's just parsing an image file header.
That some of the folks here think smaller functions are useless because they would only be called from from one function just shows they don't write enough tests.
That kind of function would be tested with couple of correct files and several, wrong ones.
Splitting everything up and testing separately, make sense if you are building a library or general user program. For program where you control whole toolchain its overkill.
You need to be able to read correct image and hopefully not segfault on bad one. And this function does that.
Simple code is easy to write, maintain, and optimize later. Despite the code looking messy, I find it easy to understand and navigate.
A counter example of truly confusing code, which kind of does similar things, would be something like this: https://github.com/ImageMagick/dcraw/blob/master/dcraw.c