I haven't really heard any comments on this issue, and I've got the impression that not many folks write these QueryResponseWriters. To me, writing one was invaluable. The use case was:
- I make the choice to make SOLR the gold source for search index data (I'm dealing with planetary science and earth science data on 4-5 projects)
- I want to drive search but also met output from SOLR (treating SOLR as a search web service, with customizable output )
- the default SOLR XML and the 5-7 output formats didn't do it for me since I have some specialized earth and planetary science use cases. E.g., on a few different projects, I need to be able to:
- output FGDC XML (yes it's a standard for earth science metadata, and also relevant for the GeoSOLR stuff)
- output custom RDF metadata
- output a particular style of JSON to plug in to some external web client, e.g., an auto-suggest that requires its own JSON format, not SOLR's
To illustrate the reason that the 5-7 output formats didn't do it for me either, I'll use an example. There may be the sense of, "well why didn't I write some Java/Ruby/PHP/Python client that called SOLR and one of it's existing wt's and then output a custom format from your favorite programming language (PL)"? The reasons are three fold:
1. SOLR advertises that the QueryResponseWriter interface is an official SOLR plugin and interface, at least according to:
- the Wiki documentation 
- the advertised published book on SOLR 
- Chris Hostetter's ApacheCon08 slides as part of the core SOLR architecture in his 50K foot view diagram 
2. If SOLR is truly a search web service, and allows for changeable output formats (evidenced by exposing the wt parameter), then why force people to use one of the existing wt's and then ask them to transform (either via a PL, or via XSLT) instead of allowing them to natively generate the specific output format type?
3. Why make o.a.l.r.QueryResponseWriter an interface and not a concrete class if it is never intended to be implemented by others, or more importantly, is kind of non-intuitive to implement?
Besides 1-3 for me, I have external COTS and OTS tools that cannot be changed and that expect data to be loaded into them in a particular format, and I'd like to plug them into SOLR and the easiest way for me to do that is with a curl/wget type operation and then a pipe into the COTS/OTS tool, and wt's are the way to go for that.
So, given the above, when I went to write a "wt" I was surprised how hard it was for me to understand the NamedList structure which is just a bag of objects that you have to unpack with unfriendly instanceof checks and recursive unmarshalling (walking the NamedList tree). All I wanted for my wt was to be able to format the output Document List or on a Doc-by-doc basis.
Anyways just wanted to provide some further fodder and discussion for this issue. To me this is important, and clearly, based on [1-3], QueryResponseWriters by definition seem to be a big piece of the SOLR architecture.
 SOLR 1.4 Enterprise Search Server, Packt Publishing, 2009.