I don't understand where the problem is exactly, there are at least two scenarios that come to mind. Both stem from:

WS can't handle more than 10 connections per second, and apparently this limit can't be easily changed.

Do you mean that your experiments show that it's physically impossible (more or less) to get more than 10 connections per second, or that if you try to do more Bad Things™ happen?

In the first case, I'd say that the real problem is that when burst arrive, some requests get discarded and this is the problem. This could probably be addressed tweaking the server's configuration, trying to have longer listen queue sizes, more childs to serve requests, etc. This seems to be indicated also by the fact that you're talking about associating 5 listeners per connector (in this case I'd use one listener with a longer queue, e.g. see the Listen parameter in IO::Socket::INET).

On the other hand, if Bad Things™ happen beyond the 10 req/s limit, then you have to put some throttling mechanism in place. But I'd ask: can we assume that it would be safe if no more than 10 contemporary WS transactions are alive at the same time? Probably yes if the service time is more than 1/10th of second, probably not if the service time is less than this. In any case, I'd try to find how many outstanding requests are good for your case, and start from this: you're eliminating the time variable.

Regarding the implementation, I'd go with IO::Select and avoid all the thread stuff, but it's just me. In this case, you end up with one listener (whose listen queue is sufficiently long according to your needs in terms of rejection probability) and up to 10 * 2 contemporary "working sockes" (one pair for each connection, one towards the WS, the other towards the client). IO::Select over 21 file descriptor shouldn't be an issue.