E-mail interchange is one of the older networking protocols. How it sends something is... and is not... always the same.
The "always the same" part is that you build a message with some number of elements (attachments, text body, etc.) and create an SMTP "capsule" which you then commit to an SMTP gateway. That transmission is more or less direct from your workstation to the gateway server because most businesses use internal routers that do not store and forward, they just act as a switching network. However, at the gateway, that "capsule" is stored in the gateway server, place in a message queue that gets sent along towards its destination.
The "not always the same" is that your service provider's gateway has some number of routing entries in the ROUTES table inside of the network components. However, there is no guarantee where those entries direct the message. Even with a U.S. Navy mainframe system, my main system's route tables had 20+ entries because of all the agencies with which we exchanged data. Sometimes routes are chosen for speed but sometimes they are chosen for security or reliability.
Each route identifies another server to which mail can be forwarded. At each hop, it is again placed into a queue (stored) until the next step in the process. The next steps along the route don't have to be SMTP servers as long as they conform to "store and forward" standards. In the case of "standard" Outlook, the starting point is the Outlook mail client and the ending point is a mail service manager such as Exchange. All the hops in between depend on the routes for all the servers in between. And there is where differences emerge.
Not saying that anyone is trying to be evasive, but there are servers where if you send mail, they intentionally re-route your traffic through multiple relay servers as a means of obscuring your point of origin. And there are services where for any reason or no reason at all, they have limited networks that do not have a lot of choices for routes because they take a "regional" approach that routes you from region to region. My mainframe actually had the ability to act as a store/forward server and it had its own mail client. Every now and then I had to intervene in my own system's mail queue if its chosen destination was not responding due to network issues. Each message had a certain number of retries before it would be dropped back into the queue (at the rear) for later retransmission. It was possible that a message would hang there for three days before it would be returned as undeliverable. (Three days was a parameter, not hard-coded, for my system.)
Therefore, a delay in the message may well depend on how it is routed as well as whether there is a store/forward component that gets backlogged for some reason.
Having said that, the next question is whether the SendObject, which exercises MAPI system libraries, does the same thing as your interactive mail client program, which also normally exercises MAPI libraries. Normally, I would say that they would do so, but it is not a requirement.