This is a known/accepted issue in Vision's numeric text field component; if you want to talk to support you can reference our internal ticket number IGN-11528.
We're delegating the internal string -> number type to an external library, and that external library goes from smallest -> largest possible presentation, and 13.3 happens to be a value that can be (acceptably to the library, at least) represented in a 32-bit float, and therefore that's what is returned.
Changing that logic in the numeric text field risks regressions in the other direction - there is no winning. We talked about the idea of introducing a "precision" editor component that worked the other way, but deferred it due to relative lack of demand.
What you could do today would be to use a formatted text field, with a regex to only allow numeric inputs, and 'bind' the writes back to a tag yourself.