The general answer is: it depends on the curve and the cryptosystem.
EDIT:
The original question mentioned ‘ECDH’ without qualification, which is a general term covering many specific cryptosystems. The question was then updated to specify the JavaCard API. For the case of the specific cryptosystems implemented by the JavaCard API, namely IEEE P1363 ECDH over short Weierstrass curves with $(x, y)$ coordinates that may or may not be compressed, point validation is almost certainly necessary. Whether the JavaCard library does it internally or whether you must write code to do it yourself, I don't know—that's a programming question you'll have to ask somewhere else.
Original answer to the more general question below:
One of the SafeCurves criteria is that the curve be safely usable for $x$-coordinate Diffie–Hellman without point validation: the cofactor of the curve and its twist must be small enough that the amount of information revealed about the secret scalar $n$ by revealing $x([n]M)$ given maliciously chosen $x(M)$ is negligible, for all possible values of $x(M)$ including ones not in the legitimate curve's subgroup or ones not on the legitimate curve at all.
Thus, for the curve Curve25519 and the Diffie–Hellman cryptosystem X25519, point validation is not necessary: at worst, the defender learns three bits of the secret scalar $n$. This is because the cofactor of the curve is 8 and the cofactor of its quadratic twist is 4, and X25519 works only in $x$ coordinates.
Thus the only invalid curve an attacker can use is the quadratic twist, by feeding in the $x$ coordinate of a point on the quadratic twist and not on the legitimate curve, and the only small subgroups an attacker can use on the curve or its quadratic twist are negligibly small.
(In correct use of X25519, legitimate users always choose $n \equiv 0 \pmod 8$ anyway so that $[n]M = \infty$ for all $M$ in all small subgroups, but the SafeCurves criteria require the leak to be negligible even if a legitimate user with slightly broken software chooses $n \not\equiv 0 \pmod 8$.)
In contrast, for the curve NIST P-224 and an analogous $x$-coordinate Diffie–Hellman cryptosystem, point validation is necessary because although NIST P-224 itself has prime order and thus no small subgroups, the order of the quadratic twist of NIST P-224 has a dangerously small 118-bit largest prime factor $\ell'$.
Without point validation, an attacker can feed $x(M_{\ell'})$ to a legitimate user where $M_{\ell'}$ is a point of order $\ell'$ on the quadratic twist, and learn $x([n]M_{\ell'})$, from which they can perform a feasible ECDLP computation to learn $n \bmod \ell'$, revealing nearly half the bits of $n$. This may be enough to figure out $n$ from the legitimate public key, or they may repeat with the other factors of the quadratic twist order.
One of the benefits of a single-coordinate ladder—such as the Montgomery ladder or Brier–Joye ladder—is that it compresses the space of inputs you must be willing to consider from $(x, y)$ values or $(x, \operatorname{sgn} y)$ values to just $x$ values. Decaf thwarts the attacks in another way by going further, at the cost of a little encoding and decoding performance: by picking a point encoding that naturally interprets every possible bit string as a valid point, so that there isn't even a way to feed a malicious point $M$ into a legitimate user.
However you do it, designing a protocol to obviate the need for input validation makes secure implementations simpler and faster: you need not remember to write an error branch in the first place for invalid values of $x(M)$, and you need not make the error branch behave sensibly.
This question was about ECDH, but what about other cryptosystems, e.g. ECDSA? Do they require point validation, or are there curves for which they require point validation? In the case of ECDSA over some curve $E/k$ and some field $k$, only the verifier is given externally supplied inputs: $A$, the public key, an element of $E(k)$; and $(r, s)$, a signature, for $r, s \in \mathbb{Z}/\ell\mathbb{Z}$, where $\ell = \#E(k)$ is the prime order of the group.
If an adversary could control $A$, the adversary could forge signatures anyway by choosing a point whose secret scalar they know.
If an adversary could find some way to control $(r, s)$ that tricks the verifier into accepting it for a public key $A$ beyond the adversary's control, that means the adversary can forge signatures. The standard signature verification equation $$r \equiv x([H(m)\,s^{-1}]G + [r s^{-1}]A) \pmod \ell$$ is supposed to thwart this anyway; if it doesn't, the signature scheme is broken.
So there are cryptosystems in which point validation doesn't matter no matter what curve you use, and you could use a variety of different curves for different purposes when you're designing a system, some of which require point validation in some cryptosystems and some of which don't. But complexity is the enemy of security, and if you can reuse the same curve—e.g., Curve25519—for many different purposes, then the cost of designing and implementing the system securely is lower.
