This seems like a lot of versions of the same thing, does anyone do things this way?
It does seem like a lot of versions that are currently the same thing.
Logically, you really have three different things going on.
You've got the model's own understanding of its domain. Part of the motivation for investing effort into modeling the core domain well is that you derive a lot of competitive advantage from it. You want a design that is easy to change, so that you can quickly adapt the model to new insights and new opportunities.
You've got the persisted representation; fundamentally, that's a message from a past version of the model to new model. Migrating your database to align it with your new model is potentially expensive, and introduces a counter force to the changes you'd otherwise like to make in the model.
Put another way, you've got a backwards compatibility concern. You don't necessarily need two different representations, but you do need to be able to decouple the model and the persistence, because they are really responding to different forces for change.
It's not absolutely critical, though; as long as you aren't sharing your persisted data to promiscuously, you can perform a migration exercise when you need to.
Your web api, however, has a very different calculus. Like persistence, it has a strong compatibility requirement; but what the API is coupled to is other consumers, outside of the boundary of the service itself. Introducing a breaking change here is extremely painful, because you have to start coordinating changes among what had been separate autonomous units.
They are three logically distinct concerns that happen to have coincident shapes today. YAGNI says that you don't have to separate those concerns yet. Who knows, maybe the project will never be successful enough to justify the work, or maybe you will never actually need to change this part of the app. If things are successful, it's likely you'll know more tomorrow about how to make the change than you do today.
Put another way: keeping the implementations of these concerns is a way of introducing technical debt.
The savvy developer treats technical debt just as the entrepreneur does financial debt. They use it. It speeds delivery, so long as it is properly managed.