But despite the meaningful, but probably over-the-top "immune to sidechannel attacks" claim on curve25519's wikipedia page ("citation needed" - indeed!), the real point to me is that in practice, using a group which is a subgroup of the full curve, is dangerous. And this is borne out, e.g. by this paper from 2017:

IACR Cryptology ePrint Archive

May the Fourth Be With You: A Microarchitectural Side Channel Attack on Several Real-World Applications of Curve25519

In recent years, applications increasingly adopt security primitives designed with better countermeasures against side channel attacks. A concrete ...

Quote: "Since Libgcrypt’s implementation of Curve25519 uses the Montgomery ladder for scalar-by-point multiplication, branchless formulas for point doubling and addition, and built-in countermeasures specially designed to resist cache attacks, our attack cannot observe high-level key dependent behavior, such as key-dependent branches or memory accesses. Instead, we achieve key extraction by combining the specific mathematical structure of Curve25519 with low-level side channel vulnerabilities deep inside Libgcrypt’s basic finite field arithmetic operations. ** By observing the cache access patterns during at most 11 scalar-by-point multiplications, our attack recovers the entire secret scalar within a few seconds**. We note that the mathematical structure that enables our attacks in also present in other popular curves such as Curve41417 [15] and Curve448 [44] (Goldilocks curve) when represented in Montgomery form [57]." (emphasis mine).

The TLDR here is that, yes, this was an implementation error, much as Monero made an implementation error in not checking the order of points, using the same curve with cofactor 8. in both cases the errors were patched. But the errors were very easy to miss and absolutely disastrous, especially in the libgcrypt case, allowing cracking of keys in seconds for any process that was sharing the same RAM. Others, like JP Aumassin (author of the excellent 'Serious Cryptography'), and apparently Matt Green, apparently shared, partly, my skepticism about not validating inputs: https://research.kudelskisecurity.com/2017/04/25/should-ecdh-keys-be-validated/ which btw links to this entertaining, concrete take on why not checking inputs is dodgy as hell:

Why not validate Curve25519 public keys could be harmful

Update: see this post for a real world protocol that is broken if Curve25519 public keys are not validated. Update: comments on Twitter ....

Do I have a point in this endless wittering? :) Well, I've always thought that engineers, and sometimes the most brilliant ones are the most guilty of this, have a tendency to over-optimise and over-engineer, and simplicity is absolutely key for robustness. There is nothing simpler than a group with NO structure - a cyclic group of prime order. And as a counterpoint, building a system which is so cool in its sophistication that you don't need to check whether external inputs are adversarial, just lacks common sense.