TL;DR

In SSH's default (and most common) deployment: Yes.  It is no more secure than telnet, but it can be better.

Apologies to Ian Betteridge

If you ask any sysadmin, they say that SSH is more secure than telnet, and they'll likely comment that opening telnet up to the Internet is reckless.  One can simulate asking general opinion with a little googling:

• "ssh is more secure than telnet": 11,500
• "telnet is more secure than ssh": 81

So, the Conventional Wisdom is that "ssh is more secure than telnet."  This must be why we see so many default deployments of SSH.  Which is why SSH are likely so common and eventually successful.

Why do people commonly think SSH is more secure?  In a word: encryption.  "SSH is more secure than telnet because it's encrypted," is a common phrase (~2.3 million google hits on that set.)  SSH's encryption protects you from two main attacks: someone sniffing your credentials and logging into the wrong machine.

Sniffing is a threat from local attackers, either a compromise on the machine itself, or something in the local network, or a system inline between the client and server.  It's certainly a risk, but it's comparatively rare to the risks cited below.

A sufficiently clever attacker could also capture your credentials by modifying your traffic to go through their systems and simply collect your credentials.  One of the key advantages of SSH over telnet is that the server authenticates itself to the client before it collects credentials from the client.

So, we have two attack scenarios that require a clever attacker acting locally to either the client or the server.  I'm going to ask that we ignore these two cases for a moment as I state my case that both telnet and ssh, by default, offer equivalent protection against brute force scans.  The attacker has time and assets on their side, they've got plenty of compromised systems to dedicate to finding more system, and each newly compromised system becomes available to be used for scanning-- think zombie outbreak.

Take a moment to think about how you're using SSH in your environment?  Is it running on the default port, accepting connections from any IP, from any system, relying only on a username/password pair?  If so, I suggest that it's no more secure than running telnet.  Not that I'm suggesting that you chuck SSH and go with telnet "because that guy at the Internet Storm Center said so."

Making it better

SSH can be an effective control.  It's just that so many people set it up only halfway.  If you are using it on the perimeter as your remote-management solution, I strongly suggest running it on a non-standard port.  Seriously, the level of scanning on port 22 is crazy (http://www.dshield.org/port.html?port=22)-- compare it to port 80.  I wouldn't use 2222 as your alternate because it looks like they might be catching on to that as well.

Use SSH as it was intended.  That means creating keys on the client-side as well.  Not those unencrypted keys either, that can be a decent was of managing systems if you can limit the permissions on the accounts correctly, but for interactive sessions from your client boxes, it's really not a good idea.  Intermediary malware loaders are looking for SSH keys in addition to other FTP credentials, so using encrypted client keys might protect a little when the client system is exposed (if you don't decrypt the key while they have their hooks into your system, that is.)

Keep an eye out for abuse.  Tools like fail2ban (http://www.fail2ban.org) can help keep out the brute force attacks.  Putting up a listener on ports 22 and 2222 and feeding that into your firewall blocklist might cut down on a lot of other abuse and spam coming into your network too.

What about two-factor?  This helps even on telnet sessions too.  Take a look at Duo:Security (https://www.duosecurity.com/) they have a personal version that's fairly inexpensive ($10 for 1000 SMS, or $20 for a hardware token.)  It's a simple PAM module.

Stop rewarding brute-force scanners.