There are several arguments about functionality.
One is that more functionality is always better.
Another is that required functionality that is not used helps make
products more expensive, less reliable and more bug-prone.
Experience also shows that functionality that isn't used tends to stop
working after a while, whether or not it is required.
So we need to find out exactly what this functionality is, whether it is important enough to warrant its cost, and whether there is in fact a difference between the two protocols.
The most commonly mentioned examples of X.400 functionality are:
Delivery, receipt and security are important enough to deserve their own sections.
Priority markers are used for ordering the queue of things to send, so that "important" stuff gets sent before "less important" stuff. It is obviously a big win if you are dealing with a network where it is impossible to get all the mail sent within a reasonable time while it is still possible to send some of it; however, this might not be the case in most of the current networks. Connectivity tends to oscillate between "none" and "plenty of room for mail", with the states between being quite rare.
I have yet to see the case being made for using deferred delivery; I am also not sure how many MTAs actually implement it. See above for the cost of implementing unused features...
Conversion in the network was something that many people regarded as important some time ago; conversions like converting Teletex to plain text, or fax images to text saying "there was a picture here, but you are not allowed to see it" are easy to imagine, sensible to apply at a central office where the capabilities of all recipients are known, and quite hard to manage in an open network.
Besides, conversion never improves a message, and it is impossible to support security functions like signatures or encryption while doing conversion in the network; the flags for "conversion prohibited" and "conversioin with loss prohibited" are there for a specific reason.
The Internet Mail approach was to regard the network as a transfer mechanism, and dump any problem onto the end user, with the proviso (in MIME) that it should *always* be possible to save "incomprehensible" information to a file for later study, conversion or disposal.
The Reliable Transfer Service used by X.400 gives you the ability to continue transferring a document after transfer was interrupted. This is a valuable service if the average time between transfer interrupts is on the same order of magnitude as the time it takes to transfer a message.
It is also a quite complex function to get right; many early X.400 implementations fudged it by negotiating it away during session establishment, or acting as if they supported it, and always replying "unable to recover" when asked for a continuation. I don't know if this practice is still common.
Again, this function's prominence in X.400 is a reflection on the state of the data communication network at the time X.400 was written; it is now a value judgment to decide if the conditions under which E-mail is now being used make it a worthwhile tradeoff.
As an aside, the IETF has recommended publication of a document (draft-ietf-mailext-checkp-01.txt, available from ftp://ds.internic.net/internet-drafts and other sites) as an Experimental protocol that gives the same functionality in SMTP; it remains to be seen if anyone actually implements and uses the functionality.
This includes: