Clearly the concern here is the possiblity of an attacker the enumerating email addresses of existing users by trying every possible combination and seeing what works, or possibly the risk of improperly disclosing the fact that a given address is associated with a user.
There's a few ways to do this, and the "forgot password" method is only one. Another is to attempt to enroll using someone else's email address and seeing if it's rejected. And depending on the application, there may be many other similar techniques.
The risk is very low, since the information you'd get is typically not very useful. Since all you get back is a "yes/no" answer (i.e. you don't get back their username or last known IP, for example), it would be difficult to leverage this knowledge in another attack. But perhaps not always impossible.
Still, in many applications I think it would be considered an acceptable risk for users in exchange for a bit of user-friendliness in your forgot-password screen assuming you take some reasonable precautions.
Of course, rate-limiting is going to be critical. You should be doing this already. If a person tries this more than a few times in a short while, you should make them slow down. And perhaps if they persist, you should make them stop and call you instead.
Another possibility is captcha -- they're not perfect, but they certainly make automation more difficult.
And another is requiring more information than just the email address. Perhaps they need to supply both their email address and their zip code or last name or favorite pokemon. Of course this opens up the slight possibility for abuse such that an attacker could use your service to link email addresses to favorite pokemons, but such an attack would probably be too costly to be worth their time, especially if you include the mitigation above.