I am sorry, but here are some points:
1) you allow user to edit files
2) you are executing files that can be edited by other users that have permissions to edit files.
you knowingly allow this to happen, where it the problem?
With "write,api,ftp", you're not allowing the API user to read files, reboot the system, change passwords, read other sensitive information, do pings, etc. and you may not want that to happen... and yet it does, even though you never intended for it to happen.
However, you have a point. As I said both at the start, and towards the end, few admins would give even just write access to an untrusted party, which combined with the limited window, makes this an unlikely attack to happen in practice.
I guess the only remotely realistic scenario where this MAY cause a problem IF you ALSO somehow manage to intervene in the middle of the delay, would be an API application that for whatever reason (say, convenience) is used for both management by end users and by admins for FTP purposes (say, to allow quick hotspot page updates). As an attacker, you'd need to rely on the management (API) part to do the work of writing a file, escalate the API user's permissions that way, and then read sensitive information or do similarly dangerous things.
But even that scenario requires an API application that has been compromised enough to, at the very least, allow arbitrary file writes by end users. In practice, an API application that writes files should check the name of the file to make sure it's not the name of a known to-be-executed script OR forbid the overwriting of files AND allow only the removal of files that it itself knows are owned by that user by other means (e.g. a database or an artificial prefix to the file name to "namespace" the uploaded files from fetched scripts and the like). So the onus is more on the API application, rather than RouterOS.
The only thing RouterOS could possibly do to prevent this (again, extremely unlikely) attack would be to not release any file write locks obtained during the script, until that script is over, and thus block other scripts and protocols (including the API) if they try to write to the same file before the script is over. This approach however risks a badly written script hanging, and thus making touched files be completely unavailable until a system reboot.