Sending passwords to websites in plain-text (e.g. a standard HTML login form on a CMS, forum or other web script) isn't secure. Similarly, sending passwords in emails (whether a new one as a "reset" or not) is insecure. Any time a password is in plain text then it is insecure.
The question is whether the account (and the site) is important enough to warrant SSL to encrypt the password in transit - security is always a trade-off of lockdown versus usability and your "risk appetite".
For Joe Bloggs' forum for him and his friends, assuming each of them follows decent security practice and has a unique password that they've not re-used on other sites(!), then the level of interest from a hacker is going to be very low. To sniff that password, they need to be on a hop between the user and the server, which is generally a high-effort task for low-value accounts (it lets him into the forum). If they re-use passwords then the value of each account is increased, but the size of the haul is still comparatively low compared to a simple phishing attack on bank accounts or social media.
If you want passwords that are encrypted before transit and aren't susceptible to replay attacks then you need to use something like Apache's mod_auth_digest, which uses a challenge-response mechanism. Your CMS or other script may have a plugin or "MOD" that enables this option.
There is no similar fix for passwords in emails - once it is sent then it is plain text and you can't do anything about it**. Just don't do it!
See PlainTextOffenders.com for examples of bad "passwords in email" practice, along with related stories of worse practices that become evident by the emails.
** This ignores the option of PGP encryption, but that requires the recipient's public PGP key so that you can encrypt it for their eyes only, which scripts generally won't have access to and many users will not have even set up