I think we'd like to move away from Hadoop configuration objects whenever we're not interacting with Hadoop features/APIs, because we don't want to be tightly coupled to the Hadoop libraries, especially in our client code. We've been doing little things here and there to try to avoid further coupling.
A couple of options which have been considered before:
Properties - pro: built-in, generic, and flexible; con: not self-descriptive about possible options
Commons Configuration - similar pros-cons as Properties, but maybe some additional tools/hierarchical parsing, options for file formats, etc.
I've been playing around with another kind of abstraction which can add some self-descriptiveness to a generic configuration store like Properties/Commons Configuration, but it's far from fully fleshed out. The basic idea is that you'd specify a Class containing a set of typed Keys as the definition of your configuration options, and pass in your configuration source for it to parse, validate, and access. https://github.com/revelc/blazon
Our current practice, however, tends to be writing fluent configuration builders which are narrowly scoped to the function in which they are being used (like BatchWriter, etc.)