consider that current application is NOT the frontmost application but the current AppleScript runner environment
Hello!
That is really something to consider! To be honest, I couldn’t find Apple Script Runner when using the ps utility to check out the priority, but SystemUIServer, has the standard priority of an application 48, so there is nothing special there. But the process is small! It takes up only 17.2 Mb of physical memory.
As I can’t stat AppleScript runner, or doesn’t know how to, I’ll continue using SystemUIServer
I said don’t show a dialog with systemUIServer. When I show a dialog with the Finder and kill it, the dialog is gone as well. But when I show a dialog in the Finder and kill systemUIServer the dialog stays on my screen and the upper right menu is gone (except for spotlight). The window server (where every application is, must, connected to) notice if an process/application lost connection with it or died. When an application died there is no use still showing objects for it so the window server removes those objects, that’s the reason why the dialog is gone. This simple test proofs that dialogs aren’t handled by systemUIServer but are handled directly by the window server.
Hello!
I figured out that along the way!
There is some points here though, one of them being, that there are some kind of communication, between the app, and the window server, in the form of aete events.
What’s next, I am not sure, or can’t explain. But what you have from before inflicts on the speed of the scripting component. (Otherwise there wouldn’t be any gain in run script from within a run handler, this is proven to be faster, because then Scripting Addtions takes over the IPC (inter process communication), which it does faster than the original scripting component of an applet).
I want to make a point of that I am not just stubborn here! 
And, there is no real reason for using the SystemUIServer to speed up the display of the display dialog, I believe it to be the context change, (memory wise) to a smaller app, with a smaller footprint, with no pending aetes that makes up any difference, if any, which I really can’t stat. Maybe it is a one way communication with the SystemUIServer through aetes But, having said that, I still believe it to make a difference on a machine with a heavy load.
I’m sorry I had to go to this extent, to bring the facts on the table.
I am still going to use this way of displaying dialogs, since ı believe in it!
I was interested in the advice given by user @McUsr about the possibility of using the SystemUIServer.app to stably display dialog inside the tell-block of other applications.
I decided to put his advice to a harder test. I was wondering if the SystemUIServer would be able to display a dialog even when there is nothing on the screen other than the full window of another application (full screen mode).
Test result: the hack works in this case too!.
It would be interesting to know if there is at least one example when this does not work
Here is my test script that you can repeat:
tell application "Finder"
display dialog "I am Finder dialog"
end tell
tell application "Skim"
tell application "SystemUIServer" to display dialog "I am Skim dialog"
set interaction mode of document 1 to full screen mode
end tell
tell application "Finder"
tell application "SystemUIServer" to display dialog "I am Finder dialog, again"
end tell
tell application "Skim"
tell application "SystemUIServer" to display dialog "I am Skim dialog, again"
end tell
NOTE: as I checked, for do shell script command inside tell blocks of applications, instead of tell current application works stably tell me and tell AppleScript as well. At least, on the Catalina.