I'm interacting with Git through GitHub for Windows, which is funny since I'll never push my repository to GitHub. I'm working on it alone and it's intended to be used only by me. I noticed that my commits are listed under "unsynced commits" and under "history" it says "no commits". Which brings me to the question, what will I achieve by pushing except my commits listed under "history"?
You are technically correct -- no real need to push if you aren't sharing the code with anyone.
Then again, your laptop has a hard drive made by the lowest bidder. Your house could burn down before the hard drive fails. You might want to look at your code remotely. Or even share it with someone.
Now, with Github, they require everything be public or you need to pay for private repositories. So if you want to keep it to yourself, you might want to check out bitbucket which will let you do git but also features free private repos.
Another option would be to save your git repository somewhere that is backed up remotely. But there are few advantages doing this rather than just using a cloud SCM provider these days.
As a distributed SCM, git distinguishes between the concepts 'make a snapshot of the working copy' (commit) and 'sync repositories' (push / pull / fetch).
If you only ever have one local clone of your repository, then it doesn't make sense to push. However, with github, you do have another clone (the one on github), and pushing your changes there has at least one advantage: backup. If your computer dies, you still have everything pushed so far on github.
Of course, that's not github's primary purpose; github is intended for sharing code, so if your project is on github, you can allow others to pull from there, clone your project, act on pull requests from their clones, or even give trusted others push access to your repository.
Another reason to push is if you use several local clones. This can be useful for various things: for example, you may want to work on two different branches at the same time, or you may want to try out possibly destructive operations on your repository; if all works as intended, you keep the modified clone (or push your changes back to the original repo), but if things go south, you can just delete the messed up clone and go back to the original one (which is still unchanged).
Some people even use git for deployment: the production version is also a git repo, and updating to a newer version is a matter of fetch and checkout (obviously, this only works if you don't need a build step). I wouldn't necessarily recommend it for serious stuff, but for small things it is a simple and pragmatic solution.
There is another reason you would like to push to a repo (even if it's, in one way or another, local): workstations.
I don't know about you, but I work in 4 different computers (1 PC at home, 1 Laptop, 1 Office PC and 1 Office Laptop) and pushing changes to a properly set up Git server in my company's server makes syncing fast and painless. Since Git is a DVCS, that's putting that advantage to use: it's not only backups, but all different codebases I'm working on can be easily merged, checked and analyzed.
It can be local if, for example, your home PC is the "server" (or the origin) and you have a home laptop - that way you can easily keep in sync.
Sidenote: People often say "I'd rather use Dropbox (or any other sync service)". The massive amounts of objects that a Git repo has makes it ridiculous to use Dropbox like that. It's an option, but I wouldn't say a good one.