In programming the spectrum is larger. When I've been asked to program with somebody, its always been a terrific drag on my productivity. I crawl thru the day, trying to be nice, and when they go the hell home I stay late and do my real work.
When it's somebody much worse (e.g., somebody new to my code base) then I'll spend a lot more time driving. As they see what to do, they jump in. Sometimes I'll force them to jump in regardless, so that they learn by doing.
That's a short-term personal productivity hit, but for me it has always been a long-term team win. There's no faster way to get somebody up to speed. And the sooner they learn The Right Way to do something, the less I'll have to clean up their novice WTF-bombs later.
When it's somebody better, that's pure fun. I learn a ton, I get to see somebody good at work, I pick up tricks, and I end up with a detailed understanding of a colleague's strengths.
Any software development approach works in the short term. In which case, do what you want. But if you're looking for a sustainable approach to building a product, sometimes you have to sacrifice short-term personal productivity to gain in the long term.
Also, "order of magnitude" is a sign you're doing it wrong. Worst case for me is circa a 30% hit; if somebody is sufficiently novice, then they're mainly along for the ride while I code and explain as I go.
However, my experience is that pair programming would work well in a senior/not as senior pairing, with the caveat, you need to have capacity on your projects to roll with this also technique.
regarding you choosing to sweat on your startup, fair play thats your choice, and possibly a good one if that's what you are passionate about. hopefully your end goal/mission is not just to make loads of money though!