I've always thought of casting as a convenience thing for the programmer working with the Entity. It has never defined the data itself. Here's some examples it was created to help with:
1. MySQL likes to return numbers as strings, but we want to be able to do strict type checks, so we cast as an int when we work with the value in our code. In this case MySQL wouldn't care so much about what it was during insert, though it's possible others might.
2. I have an array of meta data that I want to store with the value. Might be something that doesn't benefit being normalized because it's not used in relations in any way, or is a log of a JSON call, etc. The database may/may not support JSON columns, but the query builder doesn't understand them. So we serialize the value when saved to the database like we have always done. However, we would like to save ourself a step when working with the data, so we cast it as an array.
The second idea it makes a potential case for casting on the way in, but I think things might get tricky at the database level. Been a while since I've looked at that code, honestly. Could potentially work.
But basically, in my mind, casts have always been only on the way out as a convenience feature. If it doesn't cause more problems than it solves, I guess I don't have an issue.
Come to think of it, though, and a safer way to do it without modifying any code is simply to provide a
setX() method that will cast it automatically on the way in.