This is best explained by the author of RFC-1861:Email, while quite reliable, is not always timely. A good example of this is deferred messaging when a gateway is down. Suppose Mary Ghoti (fish@hugecompany.org) sends a message to Zaphod Beeblebrox's beeper (5551212@pager.pagingcompany.com). Hugecompany's gateway to the Internet is down causing Mary's message to be deferred. Mary, however, is not notified of this delay because her message has not actually failed to reach its destination. Three hours later, the link is restored, and (as soon as sendmail wakes up) the message is sent. Obviously, if Mary's page concerned a meeting that was supposed to happen 2 hours ago, there will be some minor administrative details to work out between Mary and Zaphod!On the other hand, if Mary had used her SNPP client (or simply telnetted to the SNPP gateway), she would have immediately discovered the network problem. She would have decided to invoke plan "B" and call Zaphod's pager on the telephone, ringing him that way.
The obvious difference here is not page delivery, but the immediate notification of a problem that affects your message. Standard email and SMTP, while quite reliable in most cases, cannot be positively guaranteed between all nodes at all times, making it less desirable for emergency or urgent paging. This inability to guarantee delivery could, whether rightly or wrongly, place the service provider in an uncomfortable position with a client who has just received his or her emergency page, six hours too late.
I tend to agree with this philosophy.