In general I totally agree that sequential code should just be sequential, and it should not afford more functions. Because, the each time one looks at those additional functions, in your standard programming language, the first thing one must ask oneself is, "what is the context in which this function must work? What are all the callers of this function?". In simple, sequential code, the answer is often more clear. At least, it's clear that the block of code is really only ever "called" from one place.
The disadvantage is that the block can see unrelated variables that were defined higher up in the same function - or one must add a level of indentation everywhere to protect those.
Clean 300-line functions form an unstable equilibrium point; it requires constant effort by someone who cares about code hygiene to keep them clean. More so than factored code.
Also I think the mention of golang is telling which I think is an implicit bias in his preferred style reccomendations.
I am also becoming increasingly enamored of procedural programming as a default approach. Functional is also good - it's one of my first loves - but I find that it can be similarly prone to encouraging premature abstraction. Like OOP, that problem isn't going to become so apparent until you start using it in a large, long-lived business system with ever-shifting business requirements.
That said, I think that I've got to part ways with the video around about the part where it switches to talking about how the speaker thinks good code should be structured. Especially the bit about not keeping functions small - the problem with that is, it makes it way too easy for spaghetti code to sneak in. In the same way that, in the heat of the moment, a developer in an OO language is going to start tangling together the connections among objects a bit too liberally, a developer working in a 300-line procedural function is going to start fiddling with any variable that happens to be in scope a bit too liberally. Factoring out your functions does mean you have to name all those functions (which, I realize takes effort, but I also can't agree that it's a waste of effort), but it also serves as a way of making sure everyone stays honest about shared mutable state. Maybe it wouldn't be so bad in a language that has that "nested functions that aren't closures" feature, but, like he says, such a language does not currently exist.