1) A single R process is limited to serving a single app at a time, BUT that app is able to service many concurrent sessions (meaning, a connected browser) at once. Each session will maintain its own set of inputs and outputs. Any variables you create inside the shinyServer(function(...){ ... }) closure will be specific to a particular session.
How many sessions can you service simultaneously? That depends on how fast your hardware is, and much more significantly, how much work your application is doing. With Shiny Server Open Source edition, when you run out of capacity in your single-process-per-app, that's it. Shiny Server Pro, on the other hand, can be configured to automatically launch new processes to handle additional load.
2) Going through an iframe makes by far the most sense right now, although Shiny was designed to eventually make it possible to embed Shiny apps directly in the HTML of any web application (it's possible now, I believe, though not documented).
3) Not really. Ajax calls are inherently stateless while Shiny sessions not only maintain state, they build reactive behaviors on top of that state. This makes it easy to do partial recalculation, for example. As you make your way through the Shiny tutorial it should gradually become clear how our approach differs from the typical AJAX/RPC/REST model.