Even if it takes a day for a kid at the NSA to break my custom crypto, that's better than if I use homogenous crypto that takes 2ms to break. And if everyone is using bad custom crypto, that's a lot of time needed to break each one individually. The argument is very close to that against monolithic grain cultures that, while they have the best yields, resisitance to pests, and so forth, they are also more vulnerable to as-yet-unknown diseases. Bio-diversity is a good defense against that contingency.
DH precomputation attacks are only a problem with smaller prime sizes (e.g. 1024 bits). Experts have always known to avoid small parameters, but developers copy-and-pasted them into their code without knowing they were bad.
Similarly, it is expected now that state level actors can already break 1024 bit RSA and 128 bit symmetric ciphers may be the next thing to fall. Hence their use should be avoided wherever possible.
https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombina...
In other words, OpenSSL forced developers to do crypto to use Diffie-Hellman. Unsurprisingly, developers did a poor job, and we got WeakDH/Logjam/CVE-2016-0701 as a result. The answer is not more hand-rolled crypto as you suggest, but rather better crypto libraries written by experts that leave as few details to the application developer as possible.