There are a number of issues here which need to be considered and some too often
quoted misleading statement of security through obscurity.
To address the security through obscurity statements. Making something obscure does
not automatically imply security through obscurity. The notion of security through
obscurity refers to the practice of relying solely on the obscurity for the
security. It is perfectly acceptable and in some cases even good practice to
incorporate obscurity into a security control.
As an example of the differences. Consider telnet, which is inherently insecure
because it sends passwords in plain text. Moving the telnet service from its standard
port to some other port and believing this has addressed the security issue is
security through obscurity. It has not addressed the underlying problem of plain text
passwords being transmitted and relies on nobody sniffing traffic destined to that
non-standard port to maintain security.
On the other hand, you might decide to move your ssh service to a non-standard
port. This decision might be because you have a system which only you log into and
you have noticed lots of attempts to brute force access via ssh. Moving this service
to another non-standard port will reduce the number of brute force attempts against
your ssh service. As you are the only one using it, it doesn't represent significant
inconvenience and while it has made that service more obscure, it isn't classified as
security through obscurity because moving it to another port is not the sole security
protection. You have reduced your threat exposure, but you are still using all the
other standard good practice you would have for an ssh service.
Obscurity in security is a common control and perfectly acceptable provided it is not
the only control you are relying on.
With respect to the original question as to indicating whether email or username is
valid when performing a recover password operation is a good idea, it really depends
on a lot of other factors. Security controls need to be evaluated within the context
they are being applied to. We have general 'best practice' guidelines, but these are
just that, guidelines, not rules. In general, we do not want to provide information
to attackers which they can use to assist them in their attack. However, we also need
to consider the value of the resource we are protecting.
For example, I use a RSS feed reader service. For me, this is a low risk
application. There is not a lot of value there for an attacker. If I forget my
password and try to use the forgotten password feature and it just tells me it failed
rather than telling me I had the wrong email address, then it will likely be more
frustrating than necessary. It could be I had a typo in the address I entered and
being told the address was wrong would really help. I know then that the problem is
with what I entered. Telling me something too generic prevents me from trying to
diagnose what was wrong - was it something wrong I entered, is it a problem with
their server, what?
On the other hand, I probably don't want my bank using a forgotten password feature
which will give additional information, such as my account name to an attacker. In
this case, perhaps a message stating that the forgotten password functionality has
failed and asking me to contact phone support would be more appropriate. If on the
other hand, the problem is with my gmail account, I'm probably not that concerned
because it is trivial to determine valid and invalid email addresses just using basic
SMTP commands to the server.
The basic point is, you need to balance user experience and security. You need to
understand what the threat vectors are and what the appropriate controls are for the
resource being protected. There is no always should be this or that - it all comes
down to the context.