You're right that once a local repository is pushed to a remote location, both locations contain the successive revisions. Moreover, if somebody mistakenly erases some of the files and pushes this change to the remote repository, you can still recover those files with ease from the history.
What is the risk for both copies to be lost? It depends on the infrastructure in use. Consider those scenarios:
If you're using GitHub, for instance, the risk is extremely low.
On the other hand, if the remote location is your corporate server, then maybe it is not truly remote.
What if it is in the same building where you work? What if a fire destroys both the server and your computer?
If the server is really geographically remote, could it be that a virus will propagate to both the corporate server and your machine?
Explore how remote location handles the repository. If it's a corporate server, contact the IT guy who knows how backups are managed (if he don't know the answer, this is a bad sign).
- How often do they make backups?
- Do they have off-site backups?
- Have they ever tested their backups, or they are waiting for a disaster to occur to discover that the latest working backup was made three years ago?
Even with solutions such as GitHub, on a bad day, you are at risk of losing your internet connection and at the same time screw your repository files. If waiting for internet connection to come back is not an option, then a local backup is a viable option.
It all comes to the cost of backup versus the risk of losing everything. You're probably already making a regular backup of your machine, backing up everything. Including your source code makes sense, even if you evaluated the risk of a disaster to be infinitely small.