I agree with Frans on the data access block, I cant stand it and dont reccomend it unless you like a very tight coupling your business services and data services interfaces.
In regards to the configuration block, once you do learn it, it is very valuable (IMO). IMO, the biggest value to the configuration block is using xml to create object that drive the way my applications work. The configuration tool, is a bit complex, but it is very flexible and extensibile, once again my opinion. The biggest asset to the configurtaion tool, is that once you write an application block, you can simply extend what you have written to create other blocks, and now developers and administrators can simply use the tool to configure apps and services.
I looked at the Exception & Logging block before it was re-written in the Enterprise Library. I opted not to use either of them and went with the EIF, which IMO does much more for tracing and logging especially with respect to tracing events and methods across process boundaries.
I think the reason that they can get away with calling it an Enterprise Library is simply due to the fact that most of the application blocks can be accessed and leveraged from any of the services tiers in an application, i.e. the Presentation Layer, Business Services Layer, and Data Services layer can all use a "standardized" framework, i.e. Enterprise Library.
In regards to some of the basic design/architecture patterns that you will find in the source code of the application blocks are support for localization, custom attribute useage, abstract factory patters, provider patterns, a way to implement runtime plugins using reflection, interfaces, and custom attributes, etc. etc. etc. So there really is alot of the basic every day patterns being used together as well.
But back to the point Frans was making, the internal code written is a bit OTT (which is expected from Microsoft) and is not simple, but flexibility doesnt always = simple code or less code.