I wouldn't raise limits that it is not getting near.
I'd guess that the number of threads used is tied to how many different things it is doing at once. If the activity is relatively constant, the number of (threads, files, etc) used will also be constant. Therefore raising the limits won't help you because you aren't coming near them.
Some of those limits you said it isn't near. You haven't said how many files it has opened, but I highly doubt that it is hitting 400000 open files if you only have a maximum number of connections of 1500. I also suspect that the number of threads has to be at least as big as the number of active connections, so if you're at 995 threads max, you aren't hitting the 1500 limit.
I'd think that increasing the TCP buffer size will improve sustained throughput. But if you have a typical web application, throughput isn't the issue. Round trips are. So I would expect to see little if any improvement from that.
Without knowing more about your system, and without MySQL experience, my gut says that you want to do 2 things.
1. Create one connection per Apache child, not one per page request. Creating/closing connections takes a lot of work for a database. If you're having trouble doing that fast enough, then stop doing it so often. I don't know how hard this is to do for you though.
2. Move to a reverse proxy setup. In a reverse proxy setup the browser connects to a lightweight Apache child that connects to the Apache children that connect to the database. This means that a user behind a slow modem ties up only a lightweight process, and not an expensive one that is taking database resources. Doing that will likely drop the number of active database connections that you need by a factor of 5-10 or so. I don't know MySQL, but I know that this makes Oracle much happier. (With mod_perl it also cuts overall memory requirements for the site, which means that you need fewer webservers.)
Cheers,
Ben