So there you have, one reason to take this course that is not "roll your own crypto" (which you should never do, unless you really really really know what you're doing. And even then you should check with a few people smarter than you to make sure everything is as you think it is.
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.
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.
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.
TLDR: Gate-keeping isn't useful.
TLDR: The gate is there for a reason.
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.
Gaining an understanding of how it works can help you avoid some of the pitfalls when dealing with it.
IMHO I always work better when I understand what's going on at least one layer down from where I'm playing. Nerding out on it can also help you understand how serious some attacks are and how broken your systems might be.
Never roll your own is good advice in production. Knock yourself out for test systems, for fun and exploration, but if you have some 'fun innovating' that you think might be good for real world use, pay someone that knows their stuff to audit it before trusting it. That's just common sense when it's so easy to get wrong.