Let’s define a CSS utility library as a stylesheet with many classes available to do small little one-off things. Like classes to adjust margin or padding. Classes to set colors. Classes to set specific layout properties. Classes for sizing. Utility libraries may approach these things in different ways, but seem to share that idea. Which, in essence, brings styling to the HTML level rather than the CSS level. The stylesheet becomes a dev dependency that you don’t really touch.
Using ONLY a utility library vs. sprinkling in utilities
One of the ways you can use a utility library like the ones to follow as an add-on to whatever else you’re doing with CSS. These projects tend to have different philosophies, and perhaps don’t always encourage that, but of course, you can do whatever you want. You could call that sprinkling in a utility library, and you might end up with HTML like:

Forgive a little opinion-having here, but to me, this seems like something that will feel good in the moment, and then be regrettable later. Instead of having all styling done by your own named classes, styling information is now scattered. Some styling information applied directly in the HTML via the utility classes, and some styling is applied through your own naming conventions and CSS.
The other option is to go all in on a utility library, that way you’ve moved all styling information away from CSS and into HTML entirely. It’s not a scattered system anymore.
I can’t tell you if you’ll love working with an all in utility library approach like this or not, but long-term, I imagine you’ll be happier picking either all-in or not-at-all than a tweener approach.
This is one of the definitions of Atomic CSS
You can read about that here. You could call using a utility library to do all your styling a form of “static” atomic CSS. That’s different from a “programatic” version, where you’d process markup like this:

And out would come CSS that accommodates that.
Utility Libraries
Lemme just list a bunch of them that I’ve come across, pick out some quotes of what they have to say about themselves, and a code sample.
Shed.css

Shed.css came about after I got tired of writing CSS. All of the CSS in the world has already been written, and there’s no need to rewrite it in every one of our projects.
Goal: To eliminate distraction for developers and designers by creating a set of options rather than encouraging bikeshedding, where shed gets its name.

Log In

Tachyons

Create fast loading, highly readable, and 100% responsive interfaces with as little CSS as possible.

Basscss

Using clear, humanized naming conventions, Basscss is quick to internalize and easy to reason about while speeding up development time with more scalable, more readable code.

Beard

A CSS framework for people with better things to do
Beard’s most popular and polarizing feature is its helper classes. Many people feel utility classes like the ones that Beard generates for you leads to bloat and are just as bad as using inline styles. We’ve found that having a rich set of helper classes makes your projects easier to build, easier to reason, and more bulletproof.

turretcss

Developed for design, turretcss is a styles and browser behaviour normalisation framework for rapid development of responsive and accessible websites.

Elements

A guide to the use of HTML elements and turretcsss default styling definitions including buttons, figure, media, nav, and tables.

Expressive CSS

Classes are for visual styling. Tags are for semantics.
Start from a good foundation of base html element styles.
Use utility classes for DRY CSS.
Class names should be understandable at a glance.
Responsive layout styling should be easy (fun even).

Principles

Do classes need to be ‘semantic’?

Easy to understand
+
Easy to add/remove
=
Expressive

Tailwind CSS

A Utility-First CSS Framework for Rapid UI Development
This thing doesn’t even exist yet and they have more than 700 Twitter followers. That kind of thing convinces me there is a real desire for this stuff that shouldn’t be ignored. We can get a peak at their promo site though:

Utility Libraries as Style Guides
Marvel

As Marvel continues to grow, both as a product and a company, one challenge we are faced with is learning how to refine the Marvel brand identity and apply it cohesively to each of our products. We created this styleguide to act as a central location where we house a live inventory of UI components, brand guidelines, brand assets, code snippets, developer guidelines and more.

Solid

Solid is BuzzFeed’s CSS style guide. Influenced by frameworks like Basscss, Solid uses immutable, atomic CSS classes to rapidly prototype and develop features, providing consistent styling options along with the flexibility to create new layouts and designs without the need to write additional CSS.

This is separate-but-related to the idea of CSS-in-JS
The tide in JavaScript has headed strongly toward components. Combining HTML and JavaScript has felt good to a lot of folks, so it’s not terribly surprising to see styling start to come along for the ride. And it’s not entirely just for the sake of it. There are understandable arguments for it, including things like the global nature of CSS leading toward conflicts and unintended side effects. If you can style things in such a way that never happens (which doesn’t mean you need to give up on CSS entirely), I admit I can see the appeal.
This idea of styling components at the JavaScript level does seem to largely negate the need for utility libraries. Probably largely a one or the other kind of thing.