I've always felt that much of what underlay the "vote of no confidence" was an attempt to use the EF as if it were an NHibernate clone. It isn't, and even in EF 4 attempting to use the EF as though it were an NHibernate knockoff is probably going to end in failure, although you may get a little further before failing. As a trivial example, most people use LINQ in NHibernate on a minimal basis, if at all, whereas I don't think you can be productive in EF at all unless you use LINQ quite heavily.
On the other hand, I've been quite successful at using the EF 1 on its own terms, and have managed to not allow claims people make in blog posts to get in the way of making it work for me. I look forward to using many of the new features in EF 4, but I'd be happy to work on a well-structured EF 1 project any time. (For that matter, I'm happy to work with NHibernate, too, and wouldn't criticize it for not acting like the EF.)
So I'm trying to suggest, in a somewhat delicate way, that before you can decide if "the claims made in the Vote of No Confidence are still valid (in .NET 4)..." you must first decide if those claims were ever valid for you and the way you work. If your personal understanding of O/R is hard-wired to NHibernate, then EF 4 is probably still going to seem second-rate to you. If, on the other hand, you're willing to learn the EF way of working, then probably even EF 1 will seem better than you've heard.
To address the "no confidence" claims directly, and examine both their substance and what's changed in EF 4:
INORDINATE FOCUS THE DATA ASPECT OF ENTITIES LEADS TO DEGRADED ENTITY ARCHITECTURES:
This is a misunderstanding of the Entity Framework's entity data model. (Or, a difference of opinion, if you prefer.) But either way, it's a feature, not a bug. The Entity Framework is designed around the more general case of data services, not just O/R modeling in particular. Putting behaviors on entities returned from a data service leads to a CORBA-style disaster. Unlike ORMs where you are, to some degree, stuck with whatever type comes out of the ORM blackbox, with the Entity Framework model you are expected to project onto business types. In this case, the mapped entity types will never even be materialized.
This is a substantive difference between the Entity Framework model and many other ORMs. Personally, I find separating business behaviors from O/R mapping to be quite a bit cleaner than lumping them together. You don't have to agree with this idea, but it is clearly a design decision, not an oversight.
EXCESS CODE NEEDED TO DEAL WITH LACK OF LAZY LOADING:
The EF 4, for better or worse, has lazy loading.
I say "for better or worse" because lazy loading makes it very easy to generate excess database queries. It works fine so long as you keep a close eye on what's going on under the hood, but most people don't do that. I find projection to be a better alternative to lazy loading, eager loading, or explicit loading most of the time.
Still, there are times when lazy loading is convenient. So I'm glad to see it added in EF 4.
SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES:
It's hard to know what to make of this, as some of the supporting text isn't even coherent English, e.g.:
The failure-prone canonical model approach wasn’t difficult for a lack of elaborate tooling along the lines of the Entity Framework.
This section seems to suggest that the Entity Framework imposes some kind of requirement, or at least strong bias, towards using a single, canonical data model for a complex system. I'm not sure I agree, but it's difficult to tell, given the lack of any specific example in this section. So I'll tell you my own biases on the subject, and you can agree or disagree with me:
It is often a mistake to use a single model for a large system, depending upon how large the system actually is. Nothing in the Entity Framework requires you to use a single model, however. On the other hand, the Entity Framework, especially in version 1, does not go out of its way to make it easy to combine multiple models.
Now, a single, large application for a complex system can be as big of a mistake as a single, large data model. So it would not be correct for the Entity Framework to make it easy to combine many tiny models into one overly large application; that would simply replace one problem with another.
On the other hand, I think it does make sense to make it easy to build a large system out of services partitioned in a way which suits the problem domain. I think that WCF data services, a separate technology from the Entity Framework, but one which supports the Entity Framework very well, are useful for this.
I do think that the Entity Framework could, in some future version, make it easier to combine two or three models into a single application when necessary. You can do this now, but there is some manual work involved. But as I said above, I wouldn't want to "fix" an issue of an overly large data model by facilitating/encouraging creation of an overly large application.
LACK OF PERSISTENCE IGNORANCE CAUSES BUSINESS LOGIC TO BE HARDER TO READ, WRITE, AND MODIFY, CAUSING DEVELOPMENT AND MAINTENANCE COSTS TO INCREASE AT AN EXAGGERATED RATE:
This section makes claims which I find erroneous:
The Entity Framework encourages the Anemic Domain Model anti-pattern by discouraging the inclusion of business logic in the entity classes.
See above. I think that the job of the entity types is to map between relational space in object space. Per the Single Responsibility Principle, these types should only need to be modified when their sole job changes. If business processes change, then this is a responsibility unrelated to O/R mapping. Perhaps limitations of other ORMs impose a technical barrier on separating these responsibilities. It's okay to bend rules when technology dictates, if the cost of design purity is excessive. But I strongly favor the approach of behavior-less entity types.
In its current state, EF entity classes cannot be effectively unit tested independently of the database.
This is just wrong. Whoever wrote this didn't understand what they were talking about. None of our unit tests touch the DB, ever, and many involve the EF.
In so far as the substance of the title of this section goes, there is a change for EF 4. It is now possible to have entirely persistence-ignorant entity types, if that helps your design. However, from the earliest version of the Entity Framework on words, you have been able to project onto POCOs. So persistence ignorance has always been available when required. Having persistence ignorance on the entity types themselves allows change tracking with a persistence-ignorant object. That may be useful in some cases. But it's a substantially smaller subset of cases than the bogus claims about unit testing, which lessens the impact of the point the document makes by a lot.
EXCESSIVE MERGE CONFLICTS WITH SOURCE CONTROL IN TEAM ENVIRONMENTS:
Is merging XML actually that difficult? If so, perhaps one should look into a new merge tool. I don't find this problematic.
However, there is a real issue here, although, again, it's a lot more narrow than the document claims. Rather than repeat myself, I'll just point you towards my post on that subject.
In EF 4, one can use code-first models rather than XML models in order to split up a model into many different files.