You should not use a container, but use a containerless framework such as Play instead. Regarding your points:

Single Point Of Failure: This is independent of deploying in a
container or not. I you just deploy one instance of your app and it
crashes, it’s down. For high availability you’d use multiple running
instances and load balance between them, with container or without.

Large Number of Simultaneous Connections: The Servlet API is based on a
thread-per-request model, i.e. each request will take up an entire
thread. This can be a newly spawned one, or more likely one taken
from a thread pool. So the maximum number of simultaneous requests is
determined by your container’s thread pool size, or the number of JVM threads
your hardware can handle well. That number is probably not as high as
you’d like, as each servlet container thread takes up a lot of
memory, and switching between threads is a relatively costly
operation. You’ll make much better use of your hardware with an asynchronous
approach, where each thread handles many requests concurrently, i.e.
with a framework that is not based on the Java EE Servlet API.

For more details about Play’s asynchronous approach I recommend: http://www.slideshare.net/Typesafe_Inc/why-play-framework-is-fast

Maybe try out the “Reactive Scales” app to get an indication how many requests/second Play handles on your machine.

An elaborate view of why “Java Application Servers Are Dead” is given in http://www.slideshare.net/ewolff/java-application-servers-are-dead