Rebasing isn't just about a clean project history, IMO. I'd much rather find out about a merge conflict I've created when applying a small commit to the tip of master, than when smashing two development histories together.
Absolutely. I can do without the monster-merge-from-hell (been there, done that). When rebasing is part of the established workflow, developers can rebase their feature-branches to be up-to-date with master when the time comes to offer it as a merge request (and solve any conflicts there with local knowledge of the branch). When developers are comfortable with rebasing, it is also easier to stimulate cleaning up the branch before offering it for inclusion by using interactive rebase to squash commits and edit commit messages.
There is nothing stopping you from merging the mainline history into your feature branch to pull in the latest changes. In fact you should be doing this every-so-often for any long-lived feature branch, but always before merging into the mainline.
I do integrate every so often. By fetching master and rebasing on it ;)