Not very interested, for a few reasons:
(1) It is actively harmful if the aim is to blur the distinction between local branches and remote-tracking branches. New users will be in a lot of hurt if they are not aware that the 'master' branch in their repository is unique and different from the 'master' branch of everybody else's repository and the 'origin' remote repository they cloned from.
(2) It is not necessary. You can do interesting things to the history on your local branch, like creating new commits to grow the branch, only after checking it out. And modern Git lets you say
$ git checkout topic
and it DWIMs the request to "check out the topic branch" to do the equivalent of
$ git branch -t topic origin/topic && git checkout topic
when 'topic' does not exist as your local branch and there is a single remote (i.e. 'origin') that has a remote-tracking branch of that same name 'topic'. This lets you create a corresponding local branch lazily any time you want to work on extending the work on a branch taken from the remote, and output from "git branch --list" to be meaningful: it only lists your local branch, the ones you have already said that you are interested in working on in this repository.
(3) It makes "git branch --list" output less useful if you create local branches that correspond to all the branches taken from the remote. You cannot tell which ones you have worked on and which ones you haven't even touched yet.
Having said that, it is fairly trivial to script it, if you reallywant to do so, ignoring all of the above downsides. Something like:
git for-each-ref --format='%(refname)' refs/remotes/origin/ |
sed -e 's|^refs/remotes/origin/||' -e '/^HEAD$/d' |
while read branchname
git show-ref -q --verify "refs/heads/$branchname" ||
git branch -t "$branchname" "origin/$branchname"
But for the reasons stated, it is not a particularly good way to work to start from many local branches that are copies of all the remote-tracking branches, many of which you may not even touch, so I personally do not think we would want to add such an option to "clone". The implementation would be fairly trivial, as you can see from the "trivial script" above, but it would encourage a wrong workflow.
Older Git around 1.4.x days used to conflate remote-tracking branches and local branches, and threw everything in refs/heads/hierarchy, which had the exact set of problems above, and that is why modern Git uses refs/remotes/origin/ hierarchy to store the remote-tracking branches separately, for less cluttered local branch namespace.