"Do not use exceptions for control flow" is repeated so often that people apply it without asking what it is protecting them from.

A better question

Ask whether the caller can act on the outcome. A user typing an invalid postcode is an expected outcome and belongs in the return type. A database connection disappearing mid-transaction is not, and pretending otherwise pushes error handling into every call site.

Expected outcomes belong in the signature. Broken assumptions belong in an exception.

Sealed interfaces make the first half of that pleasant in modern Java: return a result type the compiler forces you to unpack, and reserve exceptions for the cases where there is genuinely nothing sensible to do locally.