If your app is small enough, i.e. you write your own database schema (for SQL Server) and you write the only app over that schema, you don’t really need Entity Framework. In that case, you may consider LINQ to SQL.
Now let’s think big. Let’s say you are an app/service vendor but your are not a database vendor, i.e. you re-sell the data. That means data may come from different store brands and eventually from different schemas. You don’t want to implement a different adapter for each schema/store. You create an EDM and mappings for each variation that become the contract between apps and data vendors.
From the other perspective – you are a data vendor – you write a gigantic database schema and you want different kinds of applications to consume it, while you still have the freedom to evolve it. A table/column renaming would cause some significant disturbance in the app space. Therefore, you shield your implementation behind an EDM, and don’t let apps make any assumption about your implementation.
And of course, there is a large gray area in the middle where you simply want to take advantage of the programming concepts that are available in EDM/EF and not available in the database space – like inheritance, associations, materialization, and LINQ. Sitting on EDM, your application would focus on the business domain rather on the mechanics of assembling data and materializing it into objects, and reverse-engineering object changes to database rows.