I don’t know much about how serde is used in Rust, or what the alternatives are. But I do know how this mindset has affected ASP.NET developers.
The canonical ASP.NET application has a graph of entity types which maps more or less one-to-one to database tables. With the help of a few annotations, entity objects can then be serialized and deserialized autmaotically by an overcomplicated ORM-framework (which is a concept with a whole lot of problems in itself, but let’s not go there). On the other end there’s a set of DTO objects that model the server responses, and which are automatically serialized to JSON. To get from entity objects to DTOs you need to copy a whole bunch of data that is mostly, but not entirely, of the same shape. To avoid all that boilerplate you’d probably use some object-mapping library to create mappings with complicated rules. And in addition to this you need to convert to and from any application-specific models you might have. All of this instead of having just an application model populated by specific database queries and serialized directly to JSON via specific mappings. This design has come about because of the dream of convenient automatic serialization and deserialization, ignoring the fact that what you get usually isn’t what you actually want or need because the shape of the data has been optimized for some other purpose.
The problem that keeps this myth going is that if you’re used to this design, and so many are, then it really IS convenient. Because you’re comparing it to populating the entity objects and DTOs by hand. But if you look at what your application actually needs, and avoid putting entity objects into generic global stores and such, I think you’ll find that writing JSON decoders manually might lead to LESS boilerplate overall. And your component/view hierarchy might turn out better too.
Finally, one last note: Libraries and tools for automatic serialization and deserialization are usually very specific. They apply only to a single language, and usually only a single format. Once you move on to a different language, or a different data format becomes in vogue (remember XML? That one was fun…), you’ll have to use a different library or tool that probably uses a completely different API. Meanwhile, SQL is applicable to any relational database and has been for many decades. And most JSON decoders follow a combinator pattern that you’ll see again and again in functional programming. It’s not very specialized at all. Once you’ve learned these technologies you can apply them pretty much forever. That’s powerful knowledge.