I believe it's less complex to have one 'name' for the structure (or type, if you want to call it that), rather than two. In other words, when you see tns:Foo, you know what the XML inside is going to look like. If you add another level of indirection, by using XSD types, you can still do it but it's more complicated.
I don't know if I'd call that just "philosophy," perhaps "engineering philosophy." :)
You (as you note) are trading off reuse. To be able to reuse a given type, you can trade the complexity of adding 1 additional name to be able to reuse it for multiple elements. This seems a pretty good trade. It seems to me you ought to have better justification for such a sweeping rule.
Besides, the additional complexity of those type names is hidden from the standpoint of document instances.
I'm not giving up reuse, I'm just saying that if you want to use, for example, XML digital signature, then you must name your element ds:Signature. It makes *your* schemas shorter, too, since you don't have to define a new element with the old type. :)
You're guaranteed the names won't conflict, so why not just use the element name defined in the schema? It's simpler, it doesn't prevent re-use, it makes it easier for folks to "skim" your documents (I disagree with your second paragraph), and it avoids the sticky issue of XML Schema's type system, instead focusing on the document-oriented view of the XML structure.
But that's just my opinion (and others). It's not a mandatory sweeping change; feel free to ignore me.