I agree with half of the post: using EF and implementing "some sort of repository pattern" with it will often lead to all sorts of problems.
That can be fixed by sticking closer to the database, avoiding unnecessary abstractions, i.e. by using RavenDB and a Micro ORM for SQL databases. EF should really be avoided for high-traffic websites, it kills performance.
But what exactly is wrong with MVC and Web API? I actually like those. They are modern and open source. Some of the MVC 4 project templates come with DotNetOpenAuth and provide a fully functional social login system by only adding the client keys. Outside of Mono support, I don't see other advantages of Nany or ServiceStack over MVC / WebAPI.
Testing is easier with both, than it is with Web API / MVC.
Both are faster than Web API / MVC.
Routing is far superior in Nancy than MVC / Web API.
Content Negotiation is far superior in Nancy/ServiceStack than it is in WebAPI.
I could do this all day. You end up fighting the framework using MVC / WebAPI, once you build an app or service with Nancy or ServiceStack, you will be like "wow why was I using the MS stuff so long..."
But what exactly is wrong with MVC and Web API? I actually like those. They are modern and open source. Some of the MVC 4 project templates come with DotNetOpenAuth and provide a fully functional social login system by only adding the client keys. Outside of Mono support, I don't see other advantages of Nany or ServiceStack over MVC / WebAPI.