EF is slow, IMX. But I think it mainly has to do with the fact that it's an ORM, and since the application un-marshals to objects and marshals back to the data store more or less one object at a time, you lose set-based operations. If you're interacting with a lot of discrete, unrelated objects, that gets really inefficient. You can easily end up with the dreaded "row by agonizing row" pattern:

  UPDATE Student SET Grade = '04' WHERE StudentId = '12345'
  UPDATE Student SET Grade = '04' WHERE StudentId = '12346'
  UPDATE Student SET Grade = '04' WHERE StudentId = '12347'
  UPDATE Student SET Grade = '04' WHERE StudentId = '12348'
  .
  .
  .
  .
  UPDATE Student SET Grade = '04' WHERE StudentId = '12349'

Instead of:

  UPDATE Student SET Grade = '04' WHERE StudentId IN ('12345','12346','12347','12348', ...., '12349')

Oh interesting! I'll have to check it out!

Because your programmers don't know SQL and don't want to. In an ideal world of perfectly spherical programmers, choosing JavaScript would be completely orthogonal to database choice, but in reality one common symptom of JavaScriptitis is considering SQL an old relic that's too much of a pain in the ass to learn. Thankfully, MongoDB's query language is JavaScript and its result sets are JSON objects.

To be fair, this sort of feeling toward SQL is not found uniquely among JavaScript programmers; one major reason why we have ORM hell is because a previous generation of programmers did not want to leave the warm cocoon of treating data as objects in Java.