Most of this stuff can be done with aliases.
git stage
git config alias.stage '!f () { if (( $# > 0 )); then git add -- "$@"; else git add -u; fi }; f'
git unstage
git config alias.unstage 'reset --'
git undo is too ill-defind to actually implement. Sounds like the author wants it to be `git reset --hard HEAD`, but it's far more dangerous doing that while termed `git undo` than it is while termed `git reset --hard HEAD`, because people will have unrealistic expectations of what it does.
What's wrong with `git rm`? Here's a hint: you don't need to use it. Most people I know just delete the files however they want, and then run something like `git add -u` to pick up the deletions. That's exactly what the author is suggesting, but that's what people do today, so I don't see the issue.
As for git status, there's already a --short (or -s) flag that gives a very terse output. I personally use that all the time with an alias `git config alias.st 'status -sb'`.
Automatic setup? Put that info in the global config file. If git had to prompt for it, it would naturally place that info in the per-repo config file (absolutely would not make sense to automatically modify the global one), and it would be more confusing to users to be constantly re-prompted for name/email (because they switched repos). I don't see the problem with just telling new users to set up name/email globally, which every git tutorial I've seen does.
git switch
git config alias.switch checkout
For git diff confusion, just use aliases for different commands. Do not make me type STAGE, that's no friendlier to users. I personally run with the following two aliases:
git config alias.staged 'diff --cached'
git config alias.unstaged 'diff'
though I rarely use the `git unstaged` command. I also have
git config alias.both 'diff HEAD'
though I never use this one. Perhaps other names can be chosen that the author likes better.
The bit about deleting branches is misguided. `git remote` is a command that has sub-commands. `git branch` isn't. I understand that the author thinks having two styles of commands is weird, but there's not really a good alternative. Commands like `git remote` that have sub-commands would not work very well at all in the switch model (for a pathalogical example try to imagine what `git svn` would look like this way), and switch-based commands, which is most commands in git (and most commands in UNIX in general) would not do well in the sub-command model.