a few thoughts
the link cited talks about the goal being to access raw data. as bson has the BinData type that is already covered i think. however there are other potential benefits of the concept of course.
it would be a bit awkward to implement in some libraries, as "BsonElement's" are a notion and references to them can readily be passed around. however if we left out the type in each of the sub-elements, it is then a different thing that requires conversion perhaps to a regular BsonElement at some point in the library when users do certain things.
i think the encoding of arrays is a bit awkward independent of the type thing: bson arrays are also bson documents, and each array element has a field name ("0", "1", ...). the advantage is arrays can be treated as documents, but there is some space and scanning efficiency wasted in the process. i think this happened because in javascript arrays are objects. but i could imagine in some future version of the bson spec, that arrays have a different encoding than that.
in the meantime, note that you could just implement them yourself, by using BinData and a user defined subtype which for you means "typed array". then you stick whatever you want in there, and you have a couple of helper functions that push and pull the data easily. of course it isn't standardized then, but it is still bson.