Why is fail2ban not banning this attack?

The parameter logpath should be set to a path for a log file where the SSH attempts are going to be recorded in. So if that's /var/log/messages, then /var/log/secure is obviously incorrect.

Change the logpath parameter to be the correct file.

On RHEL and CentOS, authentication errors go to either /var/log/messages or /var/log secure:

# cat /etc/rsyslog.conf | grep auth
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

By default, sshd is configured with SyslogFacility set to AUTH, which goes to /var/log/messages. If you override /etc/ssh/sshd_config as follows, it will go to /var/log/secure instead:

SyslogFacility AUTHPRIV

I'm working with machines on SoftLayer cloud, and their base image configuration changed from AUTHPRIV to AUTH sometime last year.

By default, fail2ban has the following jail in /etc/fail2ban/jail.local:

[ssh]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/secure
maxretry = 6

I recommend adding a second jail to /etc/fail2ban/jail.local:

[ssh-log-messages]

enabled = true
port = ssh
filter = sshd
logpath = /var/log/messages
maxretry = 6

Afterwards, restart fail2ban to make the second jail take effect:

service fail2ban restart

An alternate approach would be to expand the sshd regex in /etc/fail2ban/filter.d/sshd.conf. There is enough information in both /var/log/secure and /var/log/messages to ban IPs. Unfortunately, fail2ban can't parse all the messages without adding alternate regex. This is left as an exercise.