For me the most valued aspect is return on my investment for learning a tool... official git cli porcelain will be around for a _long_ time, it's available almost everywhere, it gives the most power and flexibility, I can combine it with all kinds of things for new problems - Magit (or otherwise) exists in a much narrower context, I know it's probably only a subset of git porcelain to smooth over the staging and committing etc, but I prefer to stay familiar with git cli... Perhaps more critically, I've already mastered 95% of the official git cli porcelain and then some, so I suppose from my perspective my return on investment for using yet another git porcelain feels fairly low, even for the specific case of staging, i've done it so much it's second nature, and I'm generally comfortable with the serial nature of globing files over the CLI.
Edit: the relevant claim from the docs is
> Magit is an interface to the version control system Git, implemented as an Emacs package. Magit aspires to be a complete Git porcelain. While we cannot (yet) claim that Magit wraps and improves upon each and every Git command, it is complete enough to allow even experienced Git users to perform almost all of their daily version control tasks directly from within Emacs. While many fine Git clients exist, only Magit and Git itself deserve to be called porcelains.
Once I took a little while to learn Magit, it significantly reduced the number of keystrokes I needed for normal git operations.
It also made rebasing less of a chore in several ways.
It's still a bit of a tossup whether I'll use the terminal UI or Magit for a given operation, depending if I'm already in the terminal, but unlike most GUIs, I've found Magit actually reduced my friction for day-to-day work relative to the Git CLI.
If make multiple edits to different files before committing, this can be very useful to ensure that the commit makes sense, doesn't include logically unrelated changes, and so on. Or, if you follow a "commit early, commit often" approach, Magit's interface is also nice for restructuring those commits during a rebase/squash.
Perhaps it helps to think of commits as documents in their own right, as commits are effectively patch files, at which point it makes sense to use an editor to, well, edit them.