Ignoring the error in this way means that information that is meant for the receiver is not delivered to the receiver and that the receiver is not aware of this. That is why masking such errors from the user is pretty bad.
Similarly, how are unspecified enum values handled, e.g. if Smack receives <message type="unknown"/>? I think this example is comparable to the date example, since it's unexpected content, too.
Never extend XMPP in this way. If you define custom values (or attributes) for top level XMPP elements, you are extending XMPP the wrong way. Be aware that XMPP is sacred.
If I don't draw a line how to allow Smack extending, people would start extending XMPP in all kinds of ways, breaking interoperability.
For example, how would you expect an XMPP server to route a message of type "foo"? There are well defined rules for stanza routing, that's why you MUST NOT invent custom message types.
