Indeed, the industry-standard specification of ECDSA has a step (5) requiring to reject the signature if the point at infinity is encountered.
This condition can happen at least
- If the holder of the private key generated a suitable (invalid) signature, with $r=-e\,q_u^{-1}\bmod n$ or something on that tune. Granted, that reveals the private key, and (thus) an attacker not holding the private key can't willfully generate such suitable signature.
- Accidentally for random input to the signature verification. Granted, probability is so small that is can be discounted, but then good luck to convince some holders of rubber stamp about this.
- Due to some software implementation mistake or execution error in 5 or earlier, accidental of by fault injection.
It is found that anything that can go wrong at sea generally does go wrong sooner or later
Alfred Holt, in 1877-78 minutes of the Institution of Civil Engineers, published in London.
and that generalizes well to other human activities, crypto included. During well-administered conformance or security evaluation, the case at hand should even be tested, thru method 1. So something has to be done in this case, and it must not lead to the signature being accepted. Going on undisturbed with the rest of the computation would lead to undefined behavior, because there is no such thing as the x coordinate of the point at infinity. A safe, simple and unobjectionable course of action is to reject the signature and stop.
There is no risk of side-channel leakage (by timing or DPA) under the standard (and usually true) assumption that message, signature and public key are public.