If you are using the Boost.Asio based transport policy with a recent version of Boost on a platform that supports non-blocking/asynchronous I/O (epoll on Linux, kqueue on OS X/BSD, iocp on Windows) then WebSocket++ does not introduce any significant limits on simultaneous connections.
In such situations, the limits are pretty much based on OS, hardware, and application factors. The OS will limit total file descriptors in use per process (with root access this limit can be changed). High concurrency levels will require your application to be structured appropriately to handle it (primarily using short, bounded time, non-blocking handlers). Other factors will limit you in the same way that generic servers will be limited. Gigabit Ethernet can only handle so much traffic, using TLS or compression will reduce performance, etc.
I haven't done extensive performance benchmarking with 0.3.x yet, but 0.2.x in appropriately tuned applications were able to easily service 10s of thousands of concurrent clients on an i7 core.
It is the intention of the WebSocket++ architecture to scale to arbitrary connection counts given sufficient resources. If you are working on an application that scales WebSocket++ beyond 10k connections I'd be interested in more details and in addressing any bottlenecks you discover.