First, I just want to make sure we are talking about the accuracy of the ground capture and not the "accuracy" of the modeling of a structure or how "pretty" it looks... To get to your most important comment, yes the accuracy of the altimeter and constant value of the drone in flight would be the first opportunity for error to arise so in my opinion is the most important first step that you have a well-maintained and reliably functioning drone.
If you have dealt with GCP's much you will notice that when locating them in the pictures the further you are from the point the harder it is to locate that actual center as located by the GNSS receiver. This distortion is exponentially higher when you are at an oblique angle and even further away from the GCP. You can tweak the algorithms all you want and all you are doing is introducing more error into an already error-prone process.
As for my process, I sampled the same 3 jobs with 3 different flight methods being NADIR, oblique and oblique orbital. The GCPs were elevation benchmarks on each of the sites that had been surveyed in with a robotic total station and auto-level so that the accuracies were within thousandths of a foot. I then collected the GCPs with a Topcon Hiper V base and rover setup. Here arrives the first introduction of error. The GCP network went from a localization of thousandths to hundredths. (0.003-0.005' to 0.02-0.05')
Once the data was received back from the missions, the point clouds were processed with Carlson Precision 3D and a triangulated surface was created. That surface was then uploaded to the Topcon FC-5000 data collector and a surface stake operation was performed sampling the same 10 checkpoints. The checkpoints were additional points collected in between the GCPs.
The two subdivision Nadir flights were done with DroneDeploy. Due to the inefficiency of using DroneDeploy's snake pattern on linear projects Litchi was used for the Nadir. All oblique images were captured by Litchi. All image processing and GCP tagging was done with DroneDeploy. I attribute the high amount of Z error on the oblique flight for Lagos Subdivision on the type of terrain it was flying. Oblique imagery created quite allot of images with obstructions due to stockpiles and a large pond. The road project was not applicable to the orbital method.
As a last advisory, I had a colleague of mine run a Kespry mission on the Lagos Subdivision project. His average Z error was 0.28'. This was quite a bit better than the oblique flight I ran which I attribute to Kespry having algorithms that are designed for their oblique camera and the fact that they use PPK instead of GCPs. This confirms for me that we will not be paying $30k+ per year for less accurate results, more cumbersome setup and less flexible platform I think they have a good product, just not for the type of data we are consuming.