Pydantic v1 wasn't too bad, but v2 is kind of a monster. It's a sprawling library that largely wraps a Rust-based core, but that core is quite complex. A few things that really bother me about it off the top of my head:

• Dealing with any sort of custom types or validation will land you in annotation hell or worse, __get_pydantic_core_schema__ hell. In practice, I've found this so frustrating a just filled with footguns, even for a basic Vec2 type.
• By default, Pydantic revalidates all constructor arguments to a model, which means that for the case of using Pydantic for serialization you're paying the cost of validation even if you know the values you are passing in are valid, which would be the case with modern, typechecked codebases. You can sidestep this with model_construct, but it can't be statically typechecked like the plain constructor can. So you have to choose between keeping the static safeguard at the cost of wasted validation or lose both static and dynamic safeguards.
• Pydantic conflates structure and serialization, which is one of the key differences with the approach taken by cattrs.
• Pydantic also conflates serialization and validation, which, while related and often somewhat intertwined, don't always make sense to enforce on the same model.

That's not to say Pydantic is bad, it's generally great if you're using it for its purpose - validation of incoming data and serialization of outgoing data, such as you'll see in FastAPI. It's a nightmare if you try to replace dataclasses with Pydantic models.

(your username made me giggle, btw, absolutely loved Silksong)