There are a bunch of differences.
First of all, in order to just delete and clone, you have to assume that your copy of the repository is completely in sync with some remote copy and therefore it's possible to produce a better packed, but otherwise equivalent repository with a fresh clone. This is almost never the case, since repositories need not be in sync, and your local copy could have changes or branches you want to keep (even if it's bare). Doing a delete followed by a clone will lose all of this data, but a
git gc will not.
Second, you can't assume that the server will intrinsically produce a good pack with good deltas on a clone. Most Git servers will spend more time packing data periodically with better settings, but will serve requests that must pack objects dynamically with settings that produce data faster but with poorer packing, since they must combine data from multiple packs and multiple pushes. So performing a periodic repack on your own may produce better results, sometimes very significantly so.
git gc can be done in place without causing an outage, while clone-and-replace cannot be done atomically on Unix (unless you use symlinks).
git gc can also be done automatically as needed, while clone-and-replace cannot.
Fourth, if you rely on the ability to use reflogs to recover from a bad push or other mistake, clone-and-replace will lose that, while
git gc will not.
Fifth, depending on your network connection, it may be faster to just run
git gc than clone a new copy. For the reasons mentioned in the second point, you may end up transferring a lot more data, depending on how the repository is packed remotely, than you expect with a clone-and-replace.
In general, I'm not aware of anyone using clone-and-replace instead of repacking. In fact, folks with very large repositories tend to automatically fetch and preemptively pack to get better performance, not reclone all the time.