Except that if you email a new password anyone can reset someone's password by only knowing the email. It can be a real pain. Imagine being on the customer support side when an unknown third party keeps resetting someone's password.
You don't reset the user's password when he/she requests it via a web form. You send the user an e-mail with a cryptographically secure token (rather, a URL containing the token) that allows them to reset their password. You keep a table of valid tokens and expire them regularly. That will serve the same purpose without causing an inconvenience to the user.
With the Mantis Bug Tracker, users can request a password reset based on username, but it does not prevent the user from continuing to login via the existing password if the user does not get/click on the password reset link from the email.
That's more of a DoS attack than a breach of security. You can detect mass password rests and determine if that is happening. However, in practice, I've never really heard of this happening (I'm sure someone will point me to some examples). But again, this is just another sort of DoS attack.
Perhaps no perfect scheme, but you can do better than provide a "lock someone out of their account if you know their username" button as described above.
A better method is to send a special link to a user who requested to reset their password. After clicking on that link they can change it and log-in. That makes it such that the user is the only one that can trigger the reset.
The worst a third party can do is trigger an email (simply note in the email that if you did not request the email to ignore it and that your account is still safe).