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.
If it is not accepted, i will do it at the London Elixir meetup.
Even in distributed systems, coordination of data from stateless systems can be a nightmare. Requiring a bit of stickiness simplifies a lot of things.
For example, I've worked on a few large scale adserving auction platforms. One of them had the auction and impression events recorded statelessly (ie each event was generated on a random machine). This required a big hadoop job to match up all the events from a single auction. Another system used sticky events, where all events for an auction would hit the original server that ran the auction. It would store all events for an auction in memory and then flush it to the billing system when the data was finalized. Was it perfect? If the one machine crashed, all pending ad info wad lost. But that didn't happen often so the cost was negligible.