Unless a repo consisted of several independent projects, it seems it would be simplest to just have one .gitignore file at the root of the repo than various one
Pro single
Easy to find.
Hunting down exclusion rules can be quite difficult if I have multiple gitignore, at several levels in the repo.
With multiple files, you also typically wind up with a fair bit of duplication.
Pro multiple
Scopes "knowledge" to the part of the file tree where it is needed.
Since Git only tracks files, an empty .gitignore is the only way to commit an "empty" directory.
(And before Git 1.8, the only way to exclude a pattern like my/**.example was to create my/.gitignore in with the pattern **.foo. This reason doesn't apply now, as you can do /my/**/*.example.)
I much prefer a single file, where I can find all the exclusions. I've never missed per-directory .svn, and I won't miss per-directory .gitignore either.
That said, multiple gitignores are quite common. If you do use them, at least be consistent in their use to make them reasonable to work with. For example, you may put them in directories only one level from the root.