I use both - multiple cursors and keyboard macros. It is not only esthetic difference, but practical as well.
For multiple cursors you have instant feedback on multiple edge cases, and more importantly - you can undo and fix mistake immediately. While with keyboard macros you have to either: redo all from scratch or edit macro as text or execute stepwise editing - and none of them is as convenient as instant multi-undo-fix.
Moreover, for multiple cursors phases of places selection and actual editing are distinctly separated, while with keyboard macros you are doing both movement and editing in single iteration, and it is possible to catch interference between place-movement and editing-movement
On another hand, keyboard macros are very powerful.
They are not limited to "for each" workflow - steps of iterations can sequentially depend one on another.
They are also not limited to "edit/manipulate multiple places" workflow. With them you can jump between buffers/windows/frames, For instance I used this to emulate "debug step into" in source files based on extraction of file:line from trace log output in separate buffer.
Regarding performance - with Emacs I am usually working with source files, which are not big, and taking into account today's memory throughput (RAM: order of 10 GiB/s for single core; Cache order of 100 GiB/s) - sequential multi-tossing of several MiB gap buffers is not a bottleneck. Even if it would be real bottleneck - that means that bottleneck should be fixed, but not abandonment of multiple cursors. (for instance it can be fixed by switching to other data structure - multi-gap, rope, etc or maybe postpone execution for out-of-screen cursors).
That being said, I have to admit that in some cases Emacs is not fast in doing movements, editing, maybe it is related to complexity of some of major modes or maybe some other under-the-hood stuff - and this affects both keyboard macros and multiple cursors. And here, what really matters performance-wise - is that with keyboard macros you can fire-and-drink-coffee batch execution, while with multiple cursors you have to suffer multiplied latency for each single step. But multiple cursors are so connivent, that I am ready to pay occasional price of switching to keyboard macros or even to shell-command-on-region.
I understand, it can be appealing to stick to single tool and single approach, but what I observed from my experience - it is counterproductive to artificially limit yourself to single tool, and trying to find contrived excuse for not using other which is more appropriate for particular problem.
I do use and even combine Linux and Windows; statically typed and dynamically typed languages; scoped-based lifetime and garbage collection, Emacs and Vim.
I do use and even combine keyboard macros and multiple cursors.
For multiple cursors you have instant feedback on multiple edge cases, and more importantly - you can undo and fix mistake immediately. While with keyboard macros you have to either: redo all from scratch or edit macro as text or execute stepwise editing - and none of them is as convenient as instant multi-undo-fix. Moreover, for multiple cursors phases of places selection and actual editing are distinctly separated, while with keyboard macros you are doing both movement and editing in single iteration, and it is possible to catch interference between place-movement and editing-movement
On another hand, keyboard macros are very powerful. They are not limited to "for each" workflow - steps of iterations can sequentially depend one on another. They are also not limited to "edit/manipulate multiple places" workflow. With them you can jump between buffers/windows/frames, For instance I used this to emulate "debug step into" in source files based on extraction of file:line from trace log output in separate buffer.
Regarding performance - with Emacs I am usually working with source files, which are not big, and taking into account today's memory throughput (RAM: order of 10 GiB/s for single core; Cache order of 100 GiB/s) - sequential multi-tossing of several MiB gap buffers is not a bottleneck. Even if it would be real bottleneck - that means that bottleneck should be fixed, but not abandonment of multiple cursors. (for instance it can be fixed by switching to other data structure - multi-gap, rope, etc or maybe postpone execution for out-of-screen cursors). That being said, I have to admit that in some cases Emacs is not fast in doing movements, editing, maybe it is related to complexity of some of major modes or maybe some other under-the-hood stuff - and this affects both keyboard macros and multiple cursors. And here, what really matters performance-wise - is that with keyboard macros you can fire-and-drink-coffee batch execution, while with multiple cursors you have to suffer multiplied latency for each single step. But multiple cursors are so connivent, that I am ready to pay occasional price of switching to keyboard macros or even to shell-command-on-region.
I understand, it can be appealing to stick to single tool and single approach, but what I observed from my experience - it is counterproductive to artificially limit yourself to single tool, and trying to find contrived excuse for not using other which is more appropriate for particular problem. I do use and even combine Linux and Windows; statically typed and dynamically typed languages; scoped-based lifetime and garbage collection, Emacs and Vim. I do use and even combine keyboard macros and multiple cursors.