Our development team uses a dev branch for majority of commits and branch out each month for release branches. I was wondering what's the most popular model to handle bug fix commits. Commit to HEAD of monthly branch (most recent one, say 2015.Jun branch) and cherry-pick (or just rebase) to dev branch? Or commit to HEAD of dev branch, then cherry-pick it to monthly branch. Which way is better?
According to this site, it says "bugfixes from rel.branch may be continuously merged back into dev branch". Is this a good model? Are there any issues with it?
Git-Flow (your link) or similar workflows are quite commonly used. Merging release branches back into develop regularly when bugfixes are applied is a good way to go IMHO.
About some other points in your question
You could cherry-pick them into develop but it wouldn't give an explicit "merge", visible in the history. As for rebasing the release branch onto develop, you certainly don't want to do that, as develop will have recent commits not stable and not related to the ongoing release. If you meant rebase develop onto release - although technically OK I would strongly avoid that as well so as to not rewrite any of the history of the develop, especially if there are multiple contributors.
I don't recommend that either. If you're fixing a bug going into a release, it's very natural to fix it "in-place" in the release branch, and then merge release into develop to carry the fix over (or cherry-pick if you don't want to merge). Doing it the other way (fixing on develop and cherry-pick on release) doesn't guarantee that it will be compatible with the release.
To summarize my point of view, I would say it's best to be as explicit as possible. If you do a bugfix in the scope of a release, apply it on that branch then merge it to develop, where it may or may not result in a stable codebase.