This mechanism provides very little opportunity for reconfiguration. What happens if the system administrator decides to use another MTA? He has to remove /usr/lib/sendmail and replace it with an appropriate executable or symlink for the new MTA.
Unfortunately, each operating system upgrade includes a new version of sendmail. The system administrator's /usr/lib/sendmail replacement is obliterated.
Solution: UNIX vendors can move the sendmail binary elsewhere, and supply /usr/lib/sendmail as a symlink to the binary. OS upgrades will change the sendmail binary without touching the symlink. The system administrator can safely change the symlink to point to his new MTA.
/etc/mta is a refined version of this solution, dealing with several MTA features above and beyond /usr/lib/sendmail. Here's the picture:
For compatibility, /usr/lib/sendmail is symlinked to /etc/mta/send; /usr/bin/newaliases is symlinked to /etc/mta/newaliases; /usr/bin/mailq is symlinked to /etc/mta/showqueue; /usr/bin/hoststat is symlinked to /etc/mta/showfailures; /usr/bin/purgestat is symlinked to /etc/mta/clearfailures; and /bin/rmail is symlinked to /etc/mta/rmail.
I have a script that converts a sendmail installation into an installation that uses /etc/mta. Exception: The system's boot scripts should be changed to use /etc/mta/start; my script doesn't know how to do this.
Note that some vendors have changed the paths for sendmail, newaliases, et al.; for example, /usr/lib/sendmail is sometimes called /usr/sbin/sendmail, and /usr/bin/mailq is sometimes called /usr/ucb/mailq. My script checks all the usual locations and sets up appropriate symlinks.