1) A very small amount of code
2) Isolated from everything else
3) Conceptually easy to understand what it's accomplishing (even if the implementation itself is interesting and non-obvious)
Most people would kill for a colleague who wrote code like that.
No, instead what you most often get out of people like the OP is mentioning (because I too have worked with and been burned by them) is some weird pseudo-ORM they wrote from scratch because they don't like how Hibernate handles joins.
Naturally, there's no documentation or even comments because it should be obvious why paxos was poorly implemented in this weird pseudo-ORM framework. And of course, the entire codebase was rewritten overnight to use this new framework as well.
I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.
Some things just cannot be pair programmed. They are simply impenetrable to average minds at the time.
Your argument sounds like one for a Handicapper General, to be honest. (If missing the reference Google it). You want to handicap everyone actually competent with a slower partner. And before you claim the usual: it is ok to write suboptimal but simple to understand code, consider that in some cases we actually DO care for performance and size of code..