Will HTTPS negotiations slow down as more domains are added to the certificate?
The number of names is a very small amount of data overall; if it pushes delivering the certificate over a packet size threshold, the added delay won't perceptibly impact human users that have broadband or other high speed connections. The receiving computer will have up to 14 extra strings to scan; again, an imperceptible amount of overhead to any particular human user.
Qualys SSL Labs did a certificate survey a few years ago, and presented their findings at Blackhat. They found many issues that contributed to performance problems. In the case of multiple domain names, they found one certificate with 354 unrelated domain names, and the certificate was 8.2KB long! So yes, there is a line you probably don't want to cross, and 354 appears to cross it.
Another common problem they found impacting performance was that some validation chains were too long. A long time ago, some PKI architects were advocating a multi-tiered approach, where every certificate would be signed by a root CA, one or two Subordinate CAs, and one or two Policy CAs. Running through the RSA math on four different validation steps is what bogged down the clients, much more than the size of the certificates. (Qualys found 8 certificates that had a signing depth of 6!) To keep performance as high as possible, keep the signing chain as short as possible.
They also saw 43% of servers were sending too many certificates. Normally, you would include the server's cert and any intermediate signing certificates needed to validate it up to the root (the root cert is normally contained within the browser, unless it's a self-signed cert.) Many sites were wasting bandwidth by including additional certificates not needed to validate their site. One site sent a certificate file back that contained 116 certificates!
Finally, they found lots of certificates that were just plain bad. They were self-signed, expired, used weak algorithms, or had other flaws that meant their protection was less than optimal. Of all the things you need to achieve with a certificate, security is number one - performance is not. So I'd recommend using their analysis tool and finding out what they think of your setup. https://www.ssllabs.com/ssltest/index.html . I run this check every time I change my server's configuration and after updating my certificate.
UPDATE: I've switched to using an nmap script to check my server. Make sure you're running an up-to-date version of nmap, then run nmap --unprivileged -sV --script ssl-enum-ciphers -p 433 example.org. This will list the ciphers supported by the server, and provide a letter grade indicating the security of each, and an overall grade for your server. Good for finding things like out of date and insecure versions of SSL/TLS, 64 bit ciphers, etc. And you can run it on any host and port, so you can test app servers, web services, internal servers that are behind your firewalls, etc.
Since all the subject alternative names are part of the certificate and the certificate is sent by the server with each full SSL handshake more data will be sent over the wire if you have more names in the certificate. In the worst case this might result in additional packets needed or even that the full server response exceeds the initial window in TCP and thus will be delayed until the client has acknowledged the previous data. This is especially true on older systems with a low initial window size and if multiple intermediate certificates are needed and large key sizes are used which all add to the size of the response.