A couple of weeks passed since the last post, thus a little update.
I put the test app offline since its behaviour changed. I think this statement recently found on the official bubble docs is connected (I’m pretty sure it’s been recently added):
Tip: If an end-user does something that kicks off the same workflow many times within a short window of time (e.g. clicking on a button repeatedly very quickly), Bubble tries to be smart about executing that workflow: any actions that make sense to repeat (e.g. changing a thing) will be repeated and any actions that don’t make sense to repeat (e.g. navigating to another page) should not be repeated.
A lot has been written in this forum about sequence in workflows, I suggest reading this post to understand a little more about what is triggered before (and actually yes, it’s API workflows) and what after.
The use of custom events is fundamental to control order of execution.
But another thing has to be kept in mind, taken from this post of @keith 
:
… Bubble has kind of an interesting optimization around database operations. When you “Create a New Thing”, the unique ID of the Thing is created client side and the values of the fields of the Thing actually do exist for that user’s session . However, the actual creation of the Things (back on the server) might be substantially delayed.
Here’s why “result of step X” is generally safe. But be careful that it doesn’t represent the modified underlying DB value, that could (and generally will be) updated later.
With so many constraint to consider, my conclusion is that the best way of organising complex workflows (ie with API calls, changes to DB, custom events) is using custom events and “do when condition is true” (as also Bubble support suggested me after being asked).