Yeah, better in terms of saving space, but I think it confuses some people, hence I didn't use it in my above example. Previous time I recommended a co-worker to use the `push to a directory` way of copying a git repository, I made them create a bare repository, and they ended up going into the directory to verify it worked and not seeing what they expected. Cue me having to explain the difference between a normal repository and a bare one. It also confused them into thinking that a bare repository isn't just another git repository but a "special" one you can sync to, while the normal one you couldn't.
So in the end, simple is simple :) Unless you're creating remote repositories at scale, you probably won't notice a difference in storage usage.
I hear all that, but --bare is necessary in this case because git (by default) won't let you push to a non-bare filesystem branch:
~/temp/a:master $ git push backup
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 212 bytes | 212.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: is denied, because it will make the index and work tree inconsistent
remote: with what you pushed, and will require 'git reset --hard' to match
remote: the work tree to HEAD.
...
To ../b
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '../b'
So in the end, simple is simple :) Unless you're creating remote repositories at scale, you probably won't notice a difference in storage usage.