You're focusing on the wrong aspect of the post. This post is comparing web frameworks, not showing how to build a correct csv handling app.
E.g.: Most of his demos use mixed languages (Python+JavaScript). This architecture leads to madness. There are endless subtle differences between how any two languages represent data, what they can and can't express, and whether they agree on things like data validation regex syntax or not.
A proper comparison would cover issues such as internationalisation, async, data streaming[1], dependency injection, client and server validation that's kept in sync, authentication and authorization through the layers, etc...
[1] Sure, he's got a toy use-case of CSV files, but CSV files can be huge! Most JS frameworks and Rest APIs will process such tabular data as giant blobs of JSON as a single response. They can't stream, they can't handle paging or windowing, or if they can, you have to "wire that up" on the client which gets complicated rapidly. Do that! That's the demo that interests me. Not an incorrect script that will run out of memory and crash the server if you process a file big enough to be useful. Too much work for a quick demo? Well, yes, that's my point! It shouldn't be.
A comparison of how easy or cumbersome it is to write production grade apps between frameworks is much more valuable.
Otherwise we are back to comparing TODO demos.
If five apps implement an authentication flow, 4 relying on the framework and one building it from scratch because the framework doesn't provide one, then surely that should be factored into any comparisons.
If a framework comes with an opinionated templating system whereas another requires me to come up with a way to have nested templating (and whatever else I might require), then again, that should be a factor in my comparison.