I see that as entirely a front-end/SAFE Client Libs API issue. The fact that the network can provide that higher level of divisibility doesn’t mean it needs to be presented to human users. If an app decides to only support humans entering safecoin values to two decimal places, then it can enforce that. We may even only present the option to use nano safecoin at the SAFE Client Libs API where most app devs will be interfacing. That still doesn’t mean there’s any drawback to having the greater level of coin division within the type the network uses.
I believe it makes the code clearer. If that turns out to not be the case, or we find it’s worthwhile to optimise this, then we can certainly change over to use a u64. But this seems like a tiny detail to me.