* dynamic keyword
* NuGet <=> gems
* MVC scaffold <=> rails g scaffold
The only reason why I keep developing my personal projects in RoR is because of Heroku. Azure is still too expensive.
There's more to dynamic programming than the dynamic keyword. I don't want to get into which is better, but to say that C# is even in the same league as Ruby for dynamic programming, because of the dynamic keyword, is wrong - if for no other reason that properties from anonymous types (which dynamics are built on top of) are internal. Read meta programming Ruby, or try doing extensive [tb]dd with both, and you'll see how different they are (hint, you don't need DI frameworks in Ruby).
Ruby gems has a rich history, a strong community, and a proven track record. Every ruby developer has, and uses gems. Most packages are in known repositories. Gems has been extended to solve other problems (bundler). NuGet is a good and necessary start, but, again where you say "pretty close", I'd say "pretty far".
1. Ease of deployment, Heroku compared to IIS 2. Scaffolding generation, not as easy to use, fast, or smart. Extremely hard (read impossible) to customize by comparison as well 3. Routing setup, not as clean and nice, harder to customize (though there are some routing projects out there that help) 4. No database migration story
I could probably go on if I spent much time thinking about it and I'm a Rail noob compared to my .NET MVC experience.
You hinted at Ruby not needing DI - for me, that's the biggest advantage when choosing a dynamic language (in my case Python) over C#. IMO, there's something about using DI that just feels wrong (don't mean to start a flame war over that).
Anyway, that's why I use F# in .NET land: the type inference provides the best of all worlds. No need for DI, light syntax, and great runtime speed. F# sucks w/ ASP.NET MVC though.