I will also point out that there is actually some fairly deep integration code within the Mozilla editor with Thunderbird's compose backend (particularly in regards to the need to generate inline embedded images). There have been attempts to replace the editor with a more functional one in the past, but they all came to naught.
However, the key point I was trying to make still stands which is that irrespective of the state of the underlying code/Gecko editor components etc., etc., for some reason third party developers (here BlueGriffon's developers) have managed to tame the code in a much more successful way than Mozilla itself has done. The implication being that as principal developer Mozilla should have been able to do a better job than third party developers should. Thus, it amply demonstrates Mozilla's lack of commitment to the Thunderbird project per se (and that this has been so for a very long time (ipso facto, so have the bugs/problems) without Mozilla bothering to attend to them).
I am not a Thunderbird add-ons developer/TB code expert so there's little point me attempting it, but it would be very informative to find out why the BG editor works and the TB one is so brain-dead. As I see it, it's important to cut to the core of these problems if for no other reason than to show the skeptics or those who've simple requirements and find little or no problem with TB that there are real longstanding problems with Thunderbird and that some of us are not just being argumentative for the sake of it.
If you need to write something lengthy and heavily formatted, do it in a Google Doc or blog post and put a link in your email.
Thus, to be compliant, email clients should comply with these email standards—this means their editors should also format text to those standards. I contend that there is indisputable evidence that Thunderbird does not fully comply with these internet standards by a considerable margin (nor has it ever done so). Moreover, in parts, Thunderbird is so bad/non-compliant that it is essentially not fit for purpose.
This has absolutely nothing whatsoever to do with the fact that some users will only ever use a subset of those features [standards] when composing emails.
As long as users comply with the email standards, they are entitled to use any formatting they so desire. Whilst many emails are short, the fact is that there are those who often send highly formatted emails of many pages in length.
As fauigerzigerk says, in many instances, attachments are often not suitable so they must be sent in-line. This then requires the editor to handle in-line text/images etc. correctly (Thunderbird does not do this without fault).
And printing is about the most horrible thing ever invented. I only do it under threat of financial loss (return labels, letters to tax authorities). There's nothing as broken as printing. It never works flawlessly and I can't focus on printed text anyway.
Printed text has no search, no copy and paste, no changing font sizes or brightness, no hands free reading, no place to put paper without it getting fatty or full of coffee stains.
So I guess the conclusion has to be that there is no general right or wrong when it comes to the length of text in email. I depends on who you are sending it to. I pity whoever has to correspond with the both of us :-)
Frankly, on occasions, I find Thunderbird is unusable for some jobs and I end up using either an ancient copy of Eudora Mail, or Outlook or other packages to get the job done (it's just about the most idiosyncratic software package I know).
Briefly, the key issues for me are:
1. The editor sucks, big time, to call it a HTML editor at all is stretching the truth beyond reasonable recognition it is so broken. (a) It's bug-ridden in the extreme (long emails with formatting are better edited outside TB and then cut-and-pasted back in when finished but this is only a partial solution for the obvious reason that the underlying editor will then screw up perfectly good HTML). (b) Bugs develop/manifest over time whilst actually editing a single email/email reply (seems to have memory leaks). The formatting is very limited—superscripts etc., etc. require add-ons, to be implemented. Today, HTML formatting is a trivial matter (or it ought to be) so why after decades hasn't Mozilla implemented such basic formatting within Thunderbird by default. (Moreover, heaven help us when we need to add proper math formulae to the mix—just forget the notion!) (c) Global typeface change(s) is so broken it's better to save one's work before attempting them, alternatively one has to cut them into a plaintext editor (notepad etc.) to all kill formatting and start again preferably in another decent HTML editor such as BlueGriffon (which, incidentally is also based on Firefox). (d) Text size and text spacing is likewise hopeless and also has to be edited outside Thunderbird then cut-and-pasted back in. (e) There is no Format Painter! (f) Nor is there an Add/Remove quotes level facility (AND THUNDERBIRD ACTUALLY CALLS ITSELF AN EMAIL CLIENT?)—not having proper quotes handling is like buying a vehicle without wheels! It's sheer crazy stuff.
I could keep going on about editor problems and mention the issues with inserting images etc. but that's enough for here.
Finally, summarizing the matter of the Thunderbird editor issues, I again mention the BlueGriffon HTML editor by comparison, specifically because it is based on the same Firefox code as TB is. This proves that the limitations within the Thunderbird editor ARE NOT in any way limited by the underlying Firefox code. It seems to me that as BlueGriffon is open-source, the simplest immediate correction Mozilla could do to Thunderbird to fix its horrible editor would be use this BlueGriffon code as is, as it actually works!
2. The Thunderbird UI is confusing for both new and older users alike. The issue of the UI is too involved to discuss here in any detailed way except to say TB's designers should look at one of the all-time great classic email client designs for guidance: Eudora Email. (Many of us would still be using Eudora in preference to Thunderbird if Qualcomm hadn't killed it off over a decade ago—even then, many still do use it). Why reinvent the wheel if you're going to break it in the process? For starters, you cannot even dock the windows in Thunderbird. Why on earth not? (One wonders whatever went on in the minds of the original TB developers.)
3. Thunderbird's implementation of MBOX mail format is severely broken (it is dead easy to lose mail permanently from crashed indexes, compacting mail etc. The fact that Thunderbird's MBOXes are essentially incompatible with other email packages that also use MBOX is a serious issue when it comes to large site usage, maintenance etc. The MBOX problem is one of the main reasons why Outlook is often preferred to Thunderbird in corporate environments (Microsoft may be proprietary but every man and his dog either knows about its PST mail files or has a utility to maintain or fix them—not so with Thunderbird MBOXes. Moreover, Thunderbird MBOX mail files almost invariably crash when they reach the 4GB size threshold (it's a very risky business and you'd better have a decent backup strategy if you want to risk it).
4. Thunderbird even [still] has bugs in the mail addressing department (the text goes red for some reason if one does editing on the email entry). This alarms users. Furthermore, even the method of entry of CCs, BCCs is unnecessarily different to other email clients. Why unnecessarily confuse users with a redesign just for the sake of it (for heaven's sake, it seems to me the only way this could ever have happened is that TB's original developer's had never used an email package before starting on the project). Talk about this as being peculiar is a gross understatement, unfortunately such inane thinking underpins much of the basic design (Thunderbird is a quintessential, truly wonderful, example of Rube Goldberg/Heath Robinson design principles!)
5. At various times, I have tried to fix Thunderbird's limitations by applying various add-ons, and after installing sometimes up to about 35 I've just given up. Some things were fixed, others not, and there were inevitable interactions between these various add-ons. I could write a lengthy article about what is (still) not fixable with any number of add-ons; essentially though, the underlying code is so broken and haphazard that no add-on is able to fix some problems. ONE SHOULD NOT HAVE TO RELY ON ADD-ONS JUST TO OVERCOME FUNDAMENTAL DESIGN LIMITATIONS.
6. Thunderbird is slow in almost every aspect of its operation—truly unbelievably slow when compared to other packages of similar design.
From what I've read in this Thunderbird Mozilla post, I have little faith that the end product will ever satisfy serious email users (especially if lesser used features are dropped) which seems to be the proposal. Likely we'll end up with another mishmash similar to the confounded MS Office ribbon (that'll alienate most of its traditional user base—after all, Mozilla has been a past master at incompatibility for many years (every new version of Firefox has at least broken some my favourite add-ons, then there's the horrid Australis interface, and so on). Unfortunately, at Mozilla, developer culture has always taken precedent over user requirements; it would be foolhardy to think current Mozilla culture will change with a new Thunderbird design (corporate culture is always too ingrained to change that quickly).
Finally, it seems to me, that if Thunderbird's developers are actually serious about producing a better design for the majority of users (other than their own pet design) then they should open a web site to that effect and allow ordinary users to discuss and thrash out exactly what features they want within the new design. Perhaps they should include existing forks in such discussions, FossaMail for instance.
In the meantime, I reckon developers of other email clients have very little to worry about.