And the same author provides a solution for those systems as well with libhydrogen.
Though that doesn't look so super hot anymore given the recent advances on Gimli[1,2,3], but it'll likely still hold up in practice.
> but sometimes your only choice is to code and optimise it yourself
That is a critical shortcoming of the ecosystem. If you reach that point, you should be hiring a cryptographer/experienced implementer. Your follow-up question might be “Where do the cryptographers come from, then?” and the answer to that is: “PhD programs at universities, ideally”. Curiously, however, many (most?) cryptography libraries that are used in practice appear to be written by people with barely any academic background. We should be working to rectify that one way or another (send the implementers to university or pull more people from theory into implementation practice).
> you don't need to know all the attacks to protect yourself from them. What you need to know is the relevant classes of attacks, and how to void them
Some attacks, however, can be quite surprising or virtually impossible to mitigate without deep knowledge of the specific problem domain. Are we sure how to mitigate software implementations of EC scalar multiplication against differential power analysis yet?
And that's before you get to protocol design, where there are new, mysterious ways to shoot yourself in the foot (use TLS, use TLS, use Noise).
[1] https://eprint.iacr.org/2020/561.pdf
[2] https://eprint.iacr.org/2020/591.pdf
[3] https://eurocrypt.iacr.org/2020/rump/ec2020rump-paper23-slid...