And no I honestly don't see what the problem with using both is. If you're mucking with the DOM you should know the DOM. One of the things I like about jQuery is that it gets the hell out of my way. Why should I fire a method to get a property I know is available in all browsers when I can just reference it via
.someProperty instead for instance? Using both shouldn't make it harder for another UI dev to tweak your stuff if jQuery is in the mix because it's never going to have a problem with you doing that. At any time you can wrap any dom collection or object in a $ produced object wrapper by just tossing it in as an argument of the $ function and you're back in jQuery-land so it's not like you've made your code harder for somebody else to modify because that person was less comfortable with the native API.
But they should be able to read plain vanilla DOM API stuff if it's their business to tweak things at that level, regardless of their comfort-level using it. That's just the threshold of technical literacy for a proper entry-level UI-dev as far as I'm concerned. Generally speaking, of course, it can make code more legible to be consistent in the things that you do, but when you feel there's a sensible reason to go one way or the other, there's no reason not to. The key to making that decision is to know a lot about both.