John Lam shares his thoughts on Enterprise Services and says that many features of ES are replicated throughout the framework and therefore he sees little need to use ES anymore except for distributed transactions. This was my exact position about a year ago. At the time, I posted a lengthy statement with almost the same arguments to the Microsoft Regional Regional Directors (non-public) mailing list and since then I had a lot of very valuable discussions with a lot of very smart folks who mapped out the differences between what's in the framework and what's in ES and who have helped me to understand that I simply wasn't right with what I was saying.

Let me go over what John highlights:

• Load balancing. Load balancing is a filter for work where the amount of work is either not predictable or can't be handled by a single system. You load balance as close to the "topmost" client as you can, handle parts of the load and reduce the need for load balancing downstream. If you have a website or web-service, you load balance the web-tier. Will you load balance the business logic tier? Possibly, but the load generated by one web-server towards its backend is typically sufficiently predictable to eliminate the need for component load balancing and rather make not-so-dynamic assignments of backend servers to a group of web servers. Component load balancing is only really good for when you can't load-balance the presentation tier (for instance if you have GUI clients) or if you have a huge spread in execution times for a single class (if you allow users to execute ad-hoc database queries).
• ASP.NET as an application host. Hosting your business logic there is good, if you are all stateless. If you need to keep and share expensive-to-acquire application state around (such as large caches) or if you need to guard a set of limited resources that are limited for your entire web-farm, hosting there has limitations. The most important limitation of hosting business logic there is security. In ASP.NET, everything happens within the security context of the external caller (or its delegate ASPNET) and that's a problematic thing. You will want to do certain things with elevated privileges in the context of a service account and LogonUser() isn't really what you want to do in that case.
• Roles. You can make your own user and role types in the .NET framework, but not many people do. You'd have to write your own admin tools, your own infrastructure and you'd have to provide a mapping to OS roles and users for infrastructure access. If you stick with OS roles (SAM or Active Directory groups, in essence) and use the PrincipalPermissionAttribute as a replacement for ES role-based security, you will lose a level of indirection. Instead of defining a role required to access a single method on a single class in a single application right there in that application, you will have to define that in Active Directory and have it replicate throughout your AD structure. There can be very many such roles.
• Object Pool: Object pooling is a good workaround to overcome limitations of OLE DB, but that's just one aspect. It's a generic semaphore for classes. It helps implementing write access to any resource with limited or no concurrency control (the art of handling FileStream.Lock() is often long forgotten), it'll help you pre-initialize and control access to things like 3270 terminal screen-scrapers with very limited permitted concurrent sessions or maybe interfaces to physical devices of which you only have one or four (like a metal-sheet press). Nothing you couldn't do without ES, but ... it's already there and the number of folks who don't want to spend the time implementing all the required infrastructure goo is substantial.
• Transactions: Even with a single resource manager, using ES for transactions is not a bad idea for complex systems. For the simplest case that a component method creates a transaction, does work and commits the transaction, using native database connections are a good thing and the fastest choice. If a component calls another component (which may call other components itself) and the transaction shall span those components, transaction management can easily get out of hand. You will have to pass the database connection and the transaction objects around (in the case of ADO.NET), you will have to negotiate who may commit or abort and you may have to collect votes on the outcome.  Also, since components are black-boxes, you will not always know whether a component you want to roll into your transaction doesn't require a second resource manager -- in which case your native database transaction can't be used. (Update: check out Ingo Rammer's comments on the same topic)

Still, I consider John's remarks as very valid for a large number of web-applications. COM+ no longer is the automatic default for hosting business logic as it was when stuff was implemented in ASP and VB6 components instead of ASP.NET. However, ASP.NET hasn't become the automatic default for hosting all things related to a web application, either. Your mileage may vary.