CssUserAgent was started back in 2006 as a less chaotic solution to fixing browser-specific quirks when polishing up web app UIs. Originally, it was part of a larger Ajax framework that has since been modularized into smaller independent libraries.
The intention is to build valid standards-based cross-plaform CSS and sparingly use CssUserAgent to finish the job. Test your code in many browsers as early and frequently as you can. Don't just design for your favorite browser and once finished look at it in everything else. This tends to create more workarounds then are necessary.
Chill, buddy. It's just a tool. If you don't need it, don't use it. The fact is there are tons of people out there writing cryptic CSS hacks and this gives them a better option.
UserAgent-sniffing, in all its various forms, gets lots of flak in the web UI community. Typically this is because it is abused by those new to the trade. L337 haxors tend to love to bash any pragmatic shortcuts which trade code purity for time.
The reality is, as in all of life, there are trade-offs to be made. Beware "always" and "never" statements; choose wisely and use shortcuts sparingly. Deep breaths. It's going to be okay.
CssUserAgent actually predates Modernizr by a couple years; however, this is a valid point as Modernizr is a great tool. The existence of both is further evidence that browser differentiating layout is indeed a problem in need of a solution.
These two tools serve slightly different but complimentary purposes. Modernizr uses feature detection to allow differentiating layout. This works well for feature-oriented differences but some layout differences aren't necessarily the result of missing features or cannot be detected through feature testing. See the "Undetectables" topic in Modernizr's docs for specific examples. Sometimes you just need a slightly different padding or font size for one browser.
Modernizr may or may not be the right tool for the job. Keep in mind, Modernizr is also about 4x larger and requires more complex DOM testing logic on each page load. Again choose your tools based upon your needs.
As mentioned earlier, CSS hacks have been the traditional solution. These techniques rely upon bugs within various browser implementations to be able to target specific browsers. CSS hacks have many downsides, not the least of which is they typically employ invalid CSS syntax which could be misinterpreted by CSS compaction utilities. Another common issue is their behavior is largely unknown for future browsers.
Since Internet Explorer typically is the greatest deviant in web design, another common solution uses different stylesheets for IE by using IE-only conditional comments to include or exclude certain <link/> or <style/> tags. This only applies to IE, and tends to become difficult to maintainable in larger applications. Even worse is that seemingly valid uses of conditional comments can drastically slow down page load in IE-8.