I wouldn't advocate in-line SQL, but as funbi says, that's not the real alternative these days. We're using EF and this has many advantages.
Essentially it's a simple engineering trade off. We're often writing simple view / filter / edit pages for entities that will not ever number over 100. We need the pages, they don't get used more than once a week / month / whatever and would only be used by one admin at a time say. You don't need to craft procs for that. Or for filling drop downs, checking a flag, or many other simple application tasks we do all the time.
When a page is used all the time we have a simple decision tree that helps us to decide whether to use EF / paged EF / a simple stored proc / a paged stored proc as appropriate. Yes, if you let an ORM just do what it wants and don't think about it you will get horrible, horrible code and a very slow site (or whatever). With a bit of thought and craft, you can get a really well developed application. Oh and SQL injection is covered, change control is easier than with procs - change a field and the code won't compile, with an error wherever it's used.
But no - don't use in-line SQL :-)