On my current project, we just found a performance issue with the application that we are building. Early on, we knew we wanted to leverage Enterprise Library, and we integrated the use of the Data Access Block, Exception Handling Block and Configuration Block.
Since this is a large application we segmented the ASP.net application into several sub applications, each configured as an application using IIS, and each having their own configuration. But even though each app domain was separate, we wanted to be able to share a global configuration for database configuration, and some custom configuration sections we created that were applicable across app domains. Luckily I found this post by Scott Densmore: http://blogs.msdn.com/scottdensmore/archive/2005/03/01/382650.aspx. In that post you will find out how you can easily create a custom configuration context so that you don't have to read configuration off the applications own web.config.
However, in that post you will not find any mention of the need to call Dispose after creating the custom context. It wasn't until we started to use Load Runner on our application and started seeing out of Memory exception within 10 minutes that we knew there was a problem. It turns out that every time you create a context, Enterprise Library creates a file watcher on the file that will poll the config file for changes. Within 10 minutes we had 5,000 threads, 4,950 of which were polling the same file.
So just be careful if you decide to use some of the EntLib API's directly. You would be taking the responsibility to ensure all the resources are freed on your own.