I don't think any of the existing answers really answer the question. The actual relationship between the two classes is an example of the adapter pattern.
StringWriter implements all its Write... methods by forwarding on to an instance of StringBuilder that it stores in a field. This is not merely an internal detail, because StringWriter has a public method GetStringBuilder that returns the internal string builder, and also a constructor that allows you to pass in an existing StringBuilder.
So StringWriter is an adaptor that allows StringBuilder to be used as a target by code that expects to work with a TextWriter. In terms of basic behaviour there is clearly nothing to choose between them... unless you can measure the overhead of forwarding the calls, in which case StringWriter is slightly slower, but that seems very unlikely to be significant.
So why didn't they make StringBuilder implement TextWriter directly? This is a grey area, because the intention behind an interface is not necessarily always clear at first glance.
TextWriter is very nearly an interface to something that accepts a stream of characters. But it has an additional wrinkle: a property called Encoding. This implies that TextWriter is an interface to something that accepts a stream of characters and also converts them into bytes.
This is a useless vestige in StringWriter because it performs no encoding. The documentation says:
This property is necessary for some XML scenarios where a header must
be written containing the encoding used by the StringWriter. This
allows the XML code to consume an arbitrary StringWriter and generate
the correct XML header.
But that can't be right, because there is no way for us to specify the value of Encoding for StringWriter. The property always has the value UnicodeEncoding. Consequently any code that examined this property to build an XML header into would always say utf-16. For example:
var stringWriter = new StringWriter();
using (var xmlWriter = XmlWriter.Create(stringWriter))
xDocument.WriteTo(xmlWriter);
That produces the header:
<?xml version="1.0" encoding="utf-16"?>
What if you used File.WriteAllText to write your XML string to a file? By default, you'd then have a utf-8 file with a utf-16 header.
In such scenarios it would be safer to use StreamWriter, and construct it with a file path, or a FileStream, or if you want to examine the data then use a MemoryStream and so obtain an array of bytes. All these combinations would ensure that the encoding to bytes and the header generation were being guided by the same Encoding value in your StreamWriter.
The aim of the Encoding property was to allow generators of character streams to include accurate information about the encoding into the character stream itself (such as in the XML example; other examples include email headers, and so on).
But by introducing StringWriter, that link between content generation and encoding is broken, and so such automatic mechanisms stop working and become potentially error prone.
Nevertheless, StringWriter is a useful adaptor if you are careful, i.e. you understand that your content generation code should not depend on the meaningless value of the Encoding property. But that kind of caveat is commonly associated with the adaptor pattern. It's often a sort of hack to allow you to fit a square-ish-but-almost round peg into a round hole.
