It's not irrelevant. For most uses, mark the point, move, kill-region.
I vastly prefer doing operations over explicit regions, instead of composing editing operations as in vi. Especially since this maps better to other forms of editing.
vim allows you to select a region and operate on it. It sometimes necessary, but in practice, people use the compositional commands. They are faster and mentally easier. So empirically it seems your preference is different than most.
Also, what do you mean, maps better to other forms of editing?
I think you're getting close to some important points.
I think Sublime Text's multiple-cursor editing is nice because I can see where the focus is and get immediate feedback, much better than "replace-all" even if the end result would be the same. Bret Victor style.
So most of the real complexity in the interface is about region-selection, and the operations are actually trivial.
Of course, you need to first select regions (like interesting lines), then select other regions within those, others within those etc. How to chain it all in a natural way?
I want to delete a domain object (in the context of text, most objects are chars, words, sentences, paragraphs). So I tell the system delete ('d'), then what I want to delete, almost declarative (the what).
Emacs requires to explicitely tell him to create two pieces of data (begin and end marks) then ask for deletion (~the how).
Quantitatively it's also heavier, since it's a 2 keystrokes in vi, and 3 in emacs.
If you have used a Lisp Machine with something like Zmacs for an extended time, then one often manipulates with the mouse. Same sequence: mark, execute. For some things there is also modifier-click on something visual which creates a region.
Thus the whole select the object, execute sequence is the same:
* emacs keystrokes
* mouse manipulation
* Lisp functions: get the arguments, execute a function
Unfortunately I never had such pleasure. I understand a little more the appeal to have consistency between mouse and keyboard operations.
Maybe I'm more a schemer than a lisper then because even though the function call protocol is eval args, eval body, one of the nicest thing about lisps is higher order functions. Vi feels exactly like this; a move is an abstract operation that can live on its own, or be passed to another abstract operation to be combined.
To the extreme it reminds me of point-free programming where you dont even pass ~toplevel arguments, you just accumulate hof.
I've used all sorts of user interaction schemes, I don't think that's habit anymore.
It's an unnecessary explicit operative order. Like saying writing assembly code is just like C backwards, you'll get used to write callee saved arguments on the stack.
I vastly prefer doing operations over explicit regions, instead of composing editing operations as in vi. Especially since this maps better to other forms of editing.