I create 2 simple flows and save the datetime in glovar.
1st flow
Trigger : Shortcut
Action : Script
Action : Launch App : Settings
2nd flow
Trigger : App Task Started : Settings
Action : Script
Action : Notification on Screen : {dif}

- 2 test flow.png (55.78 KiB) Viewed 24742 times
And second run, I change the App Task Started trigger to UI Event - Window Opened - Settings.
Basically, what it does it to put a start anchor time, launch the settings. Wait until the launch of setting detected by Automagic accessibility (triggered the 2nd flow). Check the time and subtract it. Toast the difference (in miliseconds). Execute the flow using the shortcut, as if we test the flow inside Automagic, it will be slower, caused by the flow progress redraw.
The reason I know it is about 500 ms, is because I ever tested it using Xposed module - app context (at previous phone), and get the result around 200 ms only if using the plugin, while using built-in Automagic trigger gives around 700+ ms (there is 500+ ms difference, see the gray color).

- Comparison of latency.png (8.97 KiB) Viewed 24742 times
I try at my current phone, and got about 750-800 ms at my RN5 MIUI 9.5.17.0 Oreo 8.1. Seems to be a bit slower. I then tried tasker with a similar flow context, as you have suggested. I use Profile > app and Profile > Event > UI Event > New Windows (similar to UI event trigger). Profile App gives about 220-270 ms and New Window only about 50-100 ms (much faster). I don't give root access to tasker, so it must have improved the detection since the last time I tested it. Because at previous phone, it also hover around 700 ms as Automagic does. (it used to be tie)
I proceed to test now the new EAP version with the ability to adjust the timeout. I think maybe because I use so many UI event already, so it slows down. I should try in a new devices with minimum active flow (to reduce the possibility of slowing down) In Bliss Nougat 7.1, emulated in Virtual Box, Automagic App Task Started - classic gives about 750-850 ms average. UI event gives about the same. Tasker App profile gives about 200-250. The UI window opened, give twice 120-150 and another at around 300-400. Don't know why the duplicate event, but only the first one count, so much faster.
If I set the accessibility wait event to 200 ms, it will gives around 500-600 ms. 100 ms will give 400-500 ms. So it seems even though we deduct it till 0, we can only achieved 300-400 ms; which is somehow still slower than tasker Profile app. So I now know it is not caused by the active flow. There is something in tasker than detect the app/UI much faster.
So I retry again at my old phone. Now UI event give around 1100 ms, app task started 900-950. At the same time, tasker 5.2 gives around 520-580; still faster than Automagic.
Don't know why tasker now can detect much faster. Last year, to achieve such speed, Xposed module (AppContext) is needed, as it can hook to the process immediately as it started. 200 ms is the best. So I think
Automagic still can improve in this part : app and UI detection (tasker already). Well, Automagic doesn't degraded, it is just tasker already improved. I use 16 UI Event, or about 8% of my triggers and 6 pair of app task started/ended, about 6%. If the speed of detection can improve 4 times faster, it will surely save thousands of miliseconds everyday. But of course, I still prefer battery efficiency first. As current state of accessibility almost give no impact to my battery life. I even frequently outperform those who don't use automagic at all. (My yesterday SOT is almost 14 hours, compared to the average 10 hours for other RN5) Probably it is because I have delegated so many tasks from one-trick-pony app to Automagic, making most of my daily activity much more efficient.
Your mileage may vary. But for 2-4 times speed difference, there must be something tasker has done so it can detect it much faster.
=============
As for the fail to trigger, I think you should ask in separate thread if it is not related to this EAP version. When it fails after several trigger, what is the error produced? Any pattern you can spot in the log? Or the flow simply refuse to accept any more trigger? I remember ever have more than 100+ trigger queued, and it still run properly before hitting emergency stop.
Sorry for the long post, you ask for it
