The example is bit too trivial as the hierarchy doesn't provide much value. I would assume the base class would actually provide some useful functionality that isn't in this example or it could be eliminated entirely.
Well-named variables are interpreted and checked by the programmer; well-expressed type constraints are interpreted and checked by the compiler. Guess which one makes fewer mistakes?
C/F example is synthetic, but it doesn't make it any good - if you are operating with data that can be expressed in different units, then pick a single unit, stick with it throught the code and convert only when displaying (or passing to external party code).
Until you need to write generic code. Then it is casts everywhere and boilerplate to satisfy interfaces.
Go actually provides facilities for embedding types which helps remove some of the unnecessary boilerplate from satisfying an interface.[1]
Through embedding you can leverage the implementation of an existing type to satisfy an interface w/o writing methods to dispatch to that underlying type.
You are not explaining nothing new to me.
Might consider it again if a customer requires me to use it, otherwise I am happier with other more modern languages.