One of the advantages of emacs is that an insane level of customisation is possible. Or, more practically, the high level of customisation allows for a lot of low-hanging fruit for people to create editor macros that suit their usage.
Lol, incidentally macOS native text fields / text views support a bunch of Emacs keybindings out of box (C-f, C-b, C-n, C-p, C-a, C-e, C-k, C-d off the top of my mind), so any native Mac application with any text input can claim “inspired by Emacs” for free.
What will be interesting to see is if this changes now that zsh (which does not use readline) has become the standard...but alas, if you don't have EDITOR or VISUAL set, emacs is the default there too...
As for those curious, emacs is the readline default because readline is part of the GNU project.
Edit: Your comment was expanded as I was replying / after I replied. From which it’s quite clear you didn’t get my point.
They decided to use emacs bindings because emacs bindings are the system default for macOS programmers.
Apple's developers were also macOS's first users and they started with a terminal long before they had a working UI.
For the record I don't underestimate how much effort Apple puts into system-wide consistent behaviors in macOS. <s>Also, zsh's default keybinding mode is Emacs mode.</s> (Of course, you did mention that.)
Readline compatible keystrokes came from nextstep (sorry, I don’t dare to guess how to capitalize that). Traditional Mac OS used completely different key combinations (command left arrow instead of control-a, for example). Because of that, Carbon apps didn’t support readline-like key combinations (but system input fields did)
The two could happily coexist only because the Mac originally didn’t have control keys (it only got them for supporting terminal programs, as part of trying to make Macs sell better in business), so none of its navigation keystrokes used the control key.