Because it isn't for 0.3s -- it's for as long as it takes for the OS to manipulate the window into the correct position and size, and that may take multiple attempts.
This is a macOS problem, and KM is doing its best to work round it.
To quote from this thread:
Sadly it's a choice between slow and works (almost always) or fast and works sometimes for some people maybe. Until Apple decide to resolve it.
Only if there's also a time element. And only if that is required to be sub 1.5s (1200ms plus some leeway). And macros that depend on quick actions (whatever they are) are less transportable anyway -- you have no idea of the speed of someone else's machine, the number of foreground and background process they are running, not even the number of KM macros running concurrent with yours. All those things (and many more) will impact on an action's speed of execution.
You have a choice -- have the "Manipulate a Window" action run slowly but (nearly always) reliably, or have it run quickly and frequently fail to achieve the correct position and/or size.
But that's your choice to make for you -- not for me. Which is why a macro shouldn't force such a configuration (you could always include it as a Comment).
Aside from a theoretical interest in the whys and wherefores of this -- is there an actual problem in real world use? Do you often want to (by manual command) move a window twice within a second? Or was that just a demo and this is more a general speed issue when tiling multiple windows?