(I’m on the team)
My typical pattern is something like: define it, try it, adjust it, then apply variable times (including “infinite until error”), maybe save 1% of them. That often takes less time to do than it just took me to describe.
I use macros probably 25x for every one time I reach for multi-cursors, though to be fair, if I came the other way, I’d probably use multi-cursor more often than currently. (I used macros for 30 years before getting multi-cursors, so if both can do the job, I’ll use a macro.)
In my experience with multicursor, I don't need to be able to "inspect" the operation as the act of typing it is inspection in and of itself. Sure they aren't saveable and thus aren't editable (but you admit this is a very rare use case - I can't recall needing that, ofc you often don't know when to want what you don't have).
As for applying across a number of files, I recently added an in-editor rendering of workspace search results to VS Code, and I've created an extension that can apply edits to those search results back to the original files. This allows for performing multicursor edits across many files.
As for using variable numbers of times, this is again quite trivial with multicursor. I simply select all the instances I need (either all in one go or iteratively), and go from there. I admit there is an art to selecting the right text such that iterative selection works with a single keypress, but once you get the hang of it it becomes pretty natural. (Unless you mean "apply this N times", which again I'm not sure I've ever been in want of)
If the use case is “every day, download this file from a server and process it using pre-defined text editing commands”, multi-cursor doesn’t help you in any way that I can see.
I admit there’s a huge overlap in use, but when someone asks for macros and a product person says “how about multi-cursor instead?” I think it’s fair to raise the cases where someone asking for macros might actually want macros.
I also prefer vim's macros to multicursors, but I think it ammounts to nothing more than habit and preference.
Macros in Vim are going to be much more powerful, with movement commands and selection commands giving yo a more flexible system... I think? Hard to be objective after so many years of Vim.
Not OP, but to take a recent example (although it was in Emacs, I'm pretty sure it would work in any advanced editor), I had a macro select the second half of the open file and pipe it through sort and uniq to replace it with each unique line and their number of occurences. That's not doable with multi-cursors; their use cases intersect but don't overlap with macros ones.
My (admittedly naive) mental model of recursion is basically a loop where you bring your entire stack frame with you (or less, in the case of tail recursion).
The amount of work Microsoft is putting in this editor is amazing. Last month we got file history, that was the last thing I needed to ditch the Git GUI I had installed.