A few days ago I saw a post about a slug library. And they used specific ORM models, post and author, to store the slugs.
A slug is a part of the routing. And while they can be stored in a database, the best location is not as a field of a content table.

The basics

As I mentioned a slug is a part of the routing. In the case of a post that can be where-to-store-slugs. This can be the full path, /where-to-store-slugs, but it also can be a part of the path, /posts/where-to-store-slugs.
When your website is multilingual there can be aliases for the slug.
For the people that go old school it can a part of the query string, ?title=where-to-store-slugs.

On a mostly static website you can get away with putting the slugs in the routing configuration.
When the urls are more dynamic, I'm thinking about user created pages, the routing configuration can still be an option when you include an environment specific configuration. The problem there is that the routing configuration is cached most of the time to make the routing as fast as possible. So every slug change could create a refresh cache event.

The second fastest thing of your website is the database. So that is why the library, and others like it, use that as the storage solution.

What is wrong with storing slugs as a part of an ORM model?

Because a slug can be the full path, most libraries have an option to check the uniqueness of slug. You don't want duplicate urls.
The problem is that most libraries only check the uniqueness for the specific model, not for every model that has slugs.
For example an author can have the slug mike and a post can have a slug mike, because the post title is an acronym. Most libraries lower case the slugs they generate.

Having the slug as a part of the path is a fix, so now you have post/mike and author/mike. Now they are unique in their respective path, but you needed to change the routing to fix a uniqueness problem in the database. This is too tight of a coupling to not cause problems in the future.

A more extreme example is /mike/mike. It could be the authors page as the parent to give context to the post. But it could also be the post that is the parent to give context to the author.
I have seen editors have all sorts of weird rules to make urls unique, but there were always occasions where they managed to create duplicate urls.

What is the better solution?

As I mentioned before an environment specific configuration for dynamic urls is an option.

When you want to store the slugs in the database use a separate table. That table contains the urls with the slugs, their matching controllers and extra metadata if needed.
Another solution is to create an url tree, this is a good solution when you expect many urls with multiple levels.

The first two solutions make it easier to check the uniqueness because they centralise the slugs.
The url tree is like the prefix example, it only needs to check the uniqueness in a specific branch.

Conclusion

While a library that adds a slug to an ORM model might seem like a quick solution. I think most of the times they are a solution with a short lifespan.

The best way of thinking about slugs is to see where they fit in the website routing strategy.
When slugs are always a part of paths with prefixes or suffixes, the library could be the solution the website needs.

To be clear this is not a rant against one library in particular, I seen multiple libraries in different languages that have the same pattern.
My message for the library builders is to move the storage to the edge of the library, don't make it the main feature.

Using a slug might seems an insignificant detail, but there is always more than meets the eye.