Some .NET programmers are decidedly "old school" and conjure up reasons/excuses not to use LINQ, EF or other newer .NET methods. Some of it has to do with them having a "we've always done it this way" attitude or having bad experiences with bloated .NET DB object libraries in the past. I was this way for a while myself until, during a period of unemployment, I took the time to learn them and realized how helpful they were in building a well structured app and how much work they saved.
That said, there can be situations where using ADO.NET is preferable. For example, I recently had to write a console app that interacted with existing, complex, databases that had 100's of legacy SPs and odd table structures (no primary keys, etc). In this case, it was quicker and easier not to use EF rather than shoehorning it into a dirty legacy DB.
Remember, there's rarely a good reason to switch a existing app over to a new DB library that's working well (ie "if it ain't broke, don't fix it"). This can be a factor in some organizations. This wouldn't exclude its use by new apps although some might see an advantage in keeping the techniques used consistent.
Lastly, EF performs just fine for your average corporate CRUD type app running on desktops or an intranet site. It's done well for external internet sites where I've used it but these haven't been particularly high traffic ones.