If you are simply doing CRUD on basic setup tables and business objects, odata is the way to go. But if it’s a business object, like SalesOrder(which is a beast), that has a lot of “OnChange…” or “Change…” methods (the methods that update other fields based on another field) calling those methods is probably the way to go.
For example, if you need the Business Logic to update the Unit Price based off a Price List, you’ll need to call, oh let’s say, ChangeSellingQuantity method. Now, if you have all that information in your odata payload and call, then you are fine but you won’t get anything but the basic UpdateExt validation.
From what I’ve played around with, the odata methods don’t call any additional business logic other than UpdateExt, GetByID, GetRows methods.
You might be able to get away with a PreProcessing BPM with some custom logic to determine where the data came from and apply any additional Business Logic there prior to sending it to the base method…but that can get complicated quick.
We are learning how to use it with Microsoft Flow and Azure Logic Apps. I’ve gone back and forth between the two.
My first accomplishment with REST was to create a Microsoft Flow that updates an environment that was restored from our production environment. We update Company information, Workstations, Scheduled tasks, ect. so we don’t confuse ourselves which environment we are in after the restore. All happens in less than 30 seconds and few drop downs.
On a side note of your Orders integeration, Epicor had a cool method called SubmitNewOrder on the SalesOrderSvc, that did the basic OnChangeMethods that got me 95% of what needed to be done, but it failed to update any UD fields that were specified in the payload. Pretty disappointing. Great idea…poor execution.
As far as adding a SalesOrder using a odata POST, I couldn’t get it to work either. They still have some limitations as @Bart_Elia will tell you. They say they are “working” on it though. 
-Caleb