Your intuition is right, I would not set it up this way - with three loops in a row based off the same dataset where each subsequent loop is predicated by the success/failure per record of the previous step, it seems you would need to track all that and mutate the data before proceeding to the next step which is too much work.
I would run your newTickets query, and then for Step 2, I would loop through the results and for each record I would call another workflow (passing the json parameters you need in the body). The other workflow, I'll call it doStuff, receives the parameters you pass in as its startTrigger.data, and from there, within doStuff, you fire off your 3 resource queries (qr, email, update db) in a row. doStuff is deployed but doesn't have any actual triggers like timer etc, it just sits there waiting to be called. You could build error handling into both main workflow and doStuff (send email for failure, or update log file in db etc.)
The way you're getting your QR in its own query before email is fine, and by putting it in the doStuff you're only dealing with one record at a time so it can't be mixed up anymore.
Now, having said all that, and being relatively confident that's how it's designed to work, I'll admit I'm having issues with my own similar scenario. I'm having way too many timing related errors within my doStuff because (I think) the main workflow loop is executing too fast. I may start my own thread. Hopefully others can chime in and fix us both.