Git rebase preserves a linear history . Keep a reflog on the server (github has one built in) for cases where someone has screwed up the history. and secure shared branches to avoid clobbering it.
How do you specifically investigate the history with rebase and 10+ developers? Do you manually look into commits on the branch, or go by a single file history, or look at merge/pull requests?
Personally, I prefer looking at the context of a file change within a merge/pull request. The specific merged/pull request can be read from the merge commits. And in case a specific file history is of interest, I can backtrack from that file's associated commits.
There are tons of merge commits in the Linux repository, but no useless ones. Note how in its nature Linux process also does implicit rebasing of applied patches when they land in subtrees.