理由
- GitHubやGitLabなどのおかげで、リモートで直接masterにマージできるようになった。
- どうしても、という時以外ローカルのmasterブランチで作業する必要はないはずです。
- 間違えてmasterを壊してしまうリスクが更に減る
- ローカルのmasterブランチをメンテするコストが減る
地味なメリットに聞こえるかもしれませんが個人的にはありがたいので最後のものを詳しく説明します。
Gitの仕様上、ローカルのmasterブランチはリモートのmasterブランチを更新しても自動的には更新されません。
現状、git checkout masterしてからgit pullしないと更新できないはずです（他にも方法はありそうな気がしますが割愛します）。
この方法、一瞬でもmasterにチェックアウトしなければならないため、チェックアウトする前のブランチとローカルのmasterの差が大きい場合、ワークツリーの書き換えに時間がかかってしまいます。
一瞬しかそのワークツリーは必要ないのに。 
さらに、更新前のローカルのmasterとリモートのmasterの差が大きい場合、pullした後のワークツリーの更新にまた時間がかかってしまいます。
大きなリポジトリーでは無視できないぐらい遅いかもしれません。 
それに対してリモートのmasterブランチ（origin/master）はgit fetchしただけで更新されます！ 
pull するためだけにいちいち checkout する必要はないのです！
ローカルにmasterのない日常
リモートのmasterブランチ、origin/master は checkout しない限り概ね普通に使えます。
これから紹介するコマンド例の通り、 **使う前は都度git fetch**しておくと安心です。git-shのaliasなどに追加するのをおすすめします。
origin/master から rebaseしたいときは
git fetch && git rebase origin/master
すればいつでも最新のorigin/masterからrebaseできますし、新しいブランチを作りたいときは
git fetch && git checkout --no-track -b 新しいブランチ origin/master
しましょう。
ただし、 --no-track オプションをつけるのを忘れないでください！
追記: あるいは、予め
git config --global push.default current
あるいは
git config --global push.default nothing
と設定しておくのもよいみたいです。
(Thanks @yamasa さん！)
より安全にやるなら
git fetch && git checkout origin/master
git checkout -b 新しいブランチ
とするとよいでしょう。
間違えて checkout して「detached HEAD」になってしまっても、上記のように慌てず騒がず git checkout -b で新しいブランチを作ればいいのです。
と、言うわけで賛同できる方は「いいね！」して git branch -D master しちゃいましょう！