Well, most immediate justification for this design decision can be found in method javadocs:
you can cast the return value from this method to Spannable or Editable...
Casts mentioned above are possible only because Spannable and Editable implement CharSequence; String wouldn't allow for that.
For a deeper understanding of the design motivation, take a look at class javadocs:
TextView is a complete text editor...
Above means that TextView object is designed to support frequent changes of its content.
If getText would return immutable String, this would mean a high chance of creating multiple objects while working with TextView. This in turn would go against general approach preferred in Android and outlined in Avoid Creating Unnecessary Objects guidelines:
Object creation is never free. A generational garbage collector with per-thread allocation pools for temporary objects can make allocation cheaper, but allocating memory is always more expensive than not allocating memory.
As you allocate more objects in your app, you will force a periodic garbage collection, creating little "hiccups" in the user experience. The concurrent garbage collector introduced in Android 2.3 helps, but unnecessary work should always be avoided.
Thus, you should avoid creating object instances you don't need to...
For the sake of completeness, it is worth noting that reasoning in above guidance implicitly involves mobile applications specifics.
In particular, one can imagine desktop or server platforms having more sophisticated garbage collection, allowing developers to design immutable objects at their discretion, without worrying much about performance implications.
At mobile platforms, API designers have to take into account resource limitations of mobile devices (memory, processor, power consumption etc) that can block implementation of theoretically better approaches.