I think "not Rails" should be expanded a bit, because it risks someone saying "ok, so... sinatra?"

Web applications have some very distinct profiles. Most requests:

1. Parse HTTP

2. Parse the request body (likely JSON), build ruby objects from the data.

3. Load data from a datastore, builds ruby objects from the data.

4. Do some manipulation of data.

5. Serialize Ruby objects into a response.

Basically, because of the stateless nature of a web request, most of the work done (ignoring IO) is serializing and deserializing data. By not having Ruby be responsible for the state of our application, we make Ruby responsible for fetching and sending the state.

Now think about a stateful system (like we would have with embedded Ruby). The state is kept within Ruby for the most part. We don't have to hit a data store to restore state every time we want to do something. This significantly changes the operating profile of the application, and therefore the optimization strategy changes.