Maybe because (and this is a supposition), as I said in the first post, in an MVC architecture, servlets are not supposed to output anything to the client, but rather redirect to a view (JSP file) which will deal with the output. So there's no real need for buffering in servlets.
The initial JspWriter object is associated with the PrintWriter object of the ServletResponse in a way that depends on whether the page is or is not buffered. If the page is not buffered, output written to this JspWriter object will be written through to the PrintWriter directly, which will be created if necessary by invoking the getWriter() method on the response object. But if the page is buffered, the PrintWriter object will not be created until the buffer is flushed and operations like setContentType() are legal. Since this flexibility simplifies programming substantially, buffering is the default for JSP pages.
The key point, I think, is that it gives you the flexibility to begin writing to the response (well, in fact to the buffered JspWriter) and later, if you want to, set headers (like the mentioned content type) and do other stuff that would be illegal if the response had been committed. You may even begin writing to the JspWriter and then be able to call c:redirect or jsp:forward and there will be no IllegalStateException thrown because the reponse was not committed.
Also remember that during translation the Container may translate carriage returns and spaces into out.write("\n") (this is what tomcat does). Not to mention about template text that we may include at the very beginning of our Jsp (like the omnipresent <html><body> tags). If the JspWriter were not to be buffered, then even if you do not try to output anything explicitly in your JSP you may have an IllegalStateExcpetion when trying to set headers (even if that is the first thing that you code in your page). [ April 24, 2007: Message edited by: Sergio Tridente ]