So what is the use of persisting the events as a sequence when we are unsure about their order?
Well, we are sure about the order of events -- they are sequenced in the order that they are written, which is determined by the order in which the commands finish processing. (If you are using a single command handler, that is equivalent to the order in which the commands arrive at the handler).
What the asynchronous message queue gives you is the ability to transport messages to a (currently) unavailable recipient. The queue itself is plumbing, with higher availability because we don't need to keep swapping it out for business reasons.
Because commands can arrive "out of order", the logic in the recipient needs to include covering that contingency (assuming it is important to the business). Distributed messaging fundamentally means you never know if you have received all of the messages that you are going to eventually; at some point you are going to need to guess that you have all of the messages, or forever be paralyzed into inaction.
Think email. You get an email from Bob, you act on it, and later you get an email from Alice that she sent earlier than the mail from Bob, but hers was delayed somewhere. Now what? You proceed as best you can and get on with it.
See also Race Conditions Don't Exist.