First, those people don’t materialize out of nowhere. They usually learn from this kind of content.
Secondly, the “don’t roll your own crypto” is general advice. It means “you’re probably trying to solve a problem that already has a battle-tested solution.
A lot of really talented people clearly roll their own crypto, otherwise we wouldn’t regularly have innovation in this field (although to be fair probably 90% of the ones that get traction are from DJB).
Finally, even if you should troll your own crypto algorithm, you probably still need to apply it to your problem domain. Understanding how to think about those attack vectors helps you understand the trade offs of which algorithms to pick. This makes the collaboration with a security team/security review more meaningful.
We don't regularly get innovation from generalists who pick up and figure out cryptography on their own. Daniel J. Bernstein is a professor of cryptography. Most of the innovations we see in cryptography come from people with graduate degrees in cryptography.
If you're someone like that, you don't need advice from random people on the Internet about whether you should practice in your field. Obviously, you should. But if you're someone who mostly spends their time writing general-purpose software and just find cryptography super fascinating or morally compelling, you do need the advice, because the cryptography you come up with is likely to get somebody hurt.
Of course you need the advice. If you're going to be working with cryptography it never hurts to know just a bit so that you can have an intelligent conversation with cryptographers.
However, I'll challenge your assertion. I've never done a graduate degree in cryptography. That reading list however is a good grounding in the landscape of cryptography & doesn't cover more esoteric things that are really things that cryptographers focus on. That reading list is one I've learned by practicing over the years & making sure to diligently read the various descriptions of each encryption algorithm.
I think you're confusing developing new cryptographic algorithms and applying cryptography to day-to-day problems. DJB designs new fundamental cryptographic algorithms. Those cryptographic algorithms are part of cryptographic operations that solve common problem types (e.g. DSA type algorithms for signing/verification messages, Diffie-Hellman type algorithms for key exchange, symmetric algorithms for encryption, KDFs for key derivation, etc etc). This reading list is extremely helpful for a generalist who is given the task of "add security" to some project and needs to understand where to start: are they exchanging keys, are they signing messages, encrypting, etc.
Cryptographers may also work on new algorithm families (various zero knowledge proofs, etc). So for example, you probably have cryptographers at Signal who work on figuring out how to apply cryptography in novel ways to solve their business problems. However, it wouldn't surprise me at all if companies have generalists collaborating with cryptographers as that's generally what I've observed everywhere. Different skillsets are useful and provide different perspectives as long as everyone can mostly keep up with each other because a problem is usually multifaceted & benefits from being tackled from multiple angles at once.
This tends to be the first thing people say in response to "don't roll your own crypto". "OK, I won't design my own block ciphers". In reality, virtually all our cryptographic vulnerabilities come not from fatally damaged primitives but from they way they're hooked up together.
I think we generally agree but in practice those who end up writing the code end up being generalists. Therefore having good guidelines, tools, and trainings is invaluable even for them. Having a formal PhD in cryptography isn’t the only way to learn cryptography. That’s the beauty of science and engineering. The topics are available for many to learn independently of a formal degree. Similarly, a formal degree doesn’t mean you will actually do a good job either.
It's just not the case that most of our resilient, trusted crypto code is written by generalists. What happens instead is that specialists write code in libraries like libsodium, and generalists on successful projects go out of their way to use those libraries rather than trying to rebuild them on their own.
There are paths to cryptographic specialization that don't involve formal degrees, though it's worth mentioning that many of the best-known cryptography engineers have intense formal training. I'm not saying you need a PhD to do crypto work, but you need something.
(Just for avoidance of doubt: despite doing a bunch of work in cryptographic software security assessment, I do not myself feel qualified to do cryptography design, and avoid it for that reason.)
But the point you made above, about how cryptographic specialists can build the AES's and the P-curve specifications, and generalists can just implement them: that was false. It's a broken view of how cryptographic vulnerabilities emerge. The vulnerabilities are in the joinery, not in the primitives, and they are subtle and surprising, and if you don't study them you will re-introduce them by writing straightforward, sane code that uses well-regarded crypto primitives.
Secondly, the “don’t roll your own crypto” is general advice. It means “you’re probably trying to solve a problem that already has a battle-tested solution.
A lot of really talented people clearly roll their own crypto, otherwise we wouldn’t regularly have innovation in this field (although to be fair probably 90% of the ones that get traction are from DJB).
Finally, even if you should troll your own crypto algorithm, you probably still need to apply it to your problem domain. Understanding how to think about those attack vectors helps you understand the trade offs of which algorithms to pick. This makes the collaboration with a security team/security review more meaningful.