Did you miss the part where I mentioned code review? And the one where I said I would never invent my own primitives?

> A lot of thought can go into a few hundred lines of code.

I can attest to that. I can also confirm that most such though went in the design of the primitive itself. Most implementations in pure C are pretty straightforward, almost naive. Seriously, take a look.

> It needs math oriented people,

Mostly to design the primitives, and perform modulo arithmetic on huge numbers. That's about it.

> it needs OS-oriented people,

Only if you're writing the random number generator of an OS kernel. For the rest, portable C code is enough. You don't even need heap allocation.

> people who are experienced with exploiting systems.

Not quite. You need people who are able to write correct code, thus avoiding undefined behaviour. By the way this applies to everything, not just crypto.

> there's no reason to do it for production.

Dependency management. It's not a very good reason, but if you only use one or two primitives, importing libsodium may not be worth it.

> The problem is that in computer security defense is a lot harder than offense. If you make just one mistake, it can often lead to a compromised system.

It doesn't have to be the crypto library's fault. A single buffer overrun anywhere, and you risk giving your keys to the attacker —if that didn't already served the whole server on a silver platter. You won't be secure just because you use OpenSSL or libsodium as intended. Even if your crypto library is bug free and immune to side-channel attacks.

The greater risk is not crypto code. It's user code. Implementing your own crypto code is not going to increase the risk by much —or at all, if you're sane enough to turn on warnings, use Valgrind/Purify, write tests, and have your code reviewed.

> Anyway, there's a lot of discussion on this topic around security.stackexchange, quora, reddit etc. The consensus is that it's a terrible idea.

With all due respect, fuck consensus. Read the expert's writings. Daniel J. Bernstein in particular has written some very good stuff on why he started to write the NaCl library. Or on how he designed his primitives to be simple, and as such easily analysable by his peers. Or on how easily one can avoid timing attacks (hint: don't use AES).