Beyond that, hand-rolling JWT isn't so hard at all. When I read about some of the exploits in certain libraries, I didn't have to worry about it, as I only supported the known authority's public key in the system I was working on.
Of course, that makes the header effectively useless in practice.
There are two obvious problems with this approach to engineering:
1. You don't know what you don't know, and there is a lot to know about cryptography beyond the minimum needed to interoperate with other systems.
2. If you're engineering seriously, you know people are going to inherit your code and your design down the road, and if you're relying solely on a minimal feature set without a coherent, informed design, those people are building on sand.
It's not like he is rolling out his own crypto library. He's just rolling his own token but encrypted/signed with industry standard crypto.
It's not terrible to "roll your own JWT" if you don't actually care about interoperability. And he's right, it does sidestep a lot of issues because JWT and corresponding libraries are designed to handle far more use-cases than what he may need it for and therefore if you don't fully understand it all, you may be shipping with unsecure configuration.
If you write your own library to do it, there are strictly more things that can go wrong because at some point you're implementing a HMAC validation thingy. If you use a third party library, you're exposed to bugs that stem from JWT's design flaws even if you only allow a specific key, like the RS256 v HS256 bug I mentioned.
You are definitely right that if for some reason you must do JWT, the way to do that is to strip as much of it away as possible. In particular, if you wanted to do safe HS256-only, you'd ignore the header, decode the body and tag, and validate the tag.
To be clear, I didn't write a cryptography library... I wrote a JWT wrapper for validating JWT for the system in question. This was also before there were JWT libraries for a number of platforms. Beyond all of this, the JWT validation worked across a number of tokens generated from an alien (to the app in question) application, and rejected when it didn't validate.
Also, it was literally only validating the tag and ignoring the header... it was using an asymmetric key for signing
Of course, that makes the header effectively useless in practice.