Thunderbird 38では、メールヘッダーがMIMEエンコードされていない場合はUTF-8として扱います。
たとえば、MIMEエンコードされていないSubjectでも、UTF-8ならば文字化けせず正常に表示されます。
この仕様は、RFC 5335によるものだと思います。

当方でも、ご提示の条件下で同様の症状が出ます。

ぼくも、これを解決したくて Thunderbird 38.x をいじり回してみましたが、どうもハードコーディングされた部分での変更みたいで、ぼくのようなシロウトのエンドユーザーが設定値等を調整するレベルの操作では、対応できないように思います。

症状的には、おっしゃるとおりですが、表示される場所の名称が当方とはちょっと違います。
他所で必要があって、Thunderbird の各部の名称を示した画像を作ったものがあるので、紹介しておきます。
http://meitner.jimdo.com/2015/07/03/thunderbird-reference-01/

当方では、受信メッセージ（とくに過去に受信したもの）の件名が、上記の図で示せば [スレッドペイン] で文字化けします。
しかし、[メッセージペイン] の上部、[ヘッダビュー] では文字化けしません。

精密なテストをおこなったわけではありませんが、次のようなことは試しました。

[スレッドペイン] に表示される情報は msf ファイルから読み込まれるのですが、完全に同じメッセージデータで構成されたフォルダを、Thunderbird 38.1.0 と 31.8.0 に読み込ませると、38.1.0 のスレッドペインだけ文字化けします。
この結果からは、データ的に同一の msf ファイルに対する読み込み時の解釈が、バージョンによって異なるのであろうことが推測されます。
シロウト考えですが、msf の読み込みの際のデコード処理が、送信のときのエンコーディングが UTF-8 に固定されたのと同じような感じで固定（あるいは別の仕様変更）されたのかもしれないと想像しています。

送信時のメールヘッダに含まれる非 ASCII 文字のエンコーディングが UTF-8 に固定された件も、Thunderbird 38.x 系での文字処置回りの変更ではありますが、これは本件の文字化けとは区別して考えたほうがいいと思います。
Thunderbird 38.x から送信さえたメッセージを受信して文字化けを起こすのは、主に "Unicode への対応が不十分な古い仕様の環境" のようです。
現状で必要十分な程度に Unicode に対応している環境では、文字化けは起こっていないと思います。実際、ぼくが Thunderbird で直接メッセージやり取りしている相手については、文字化けを起こしたという受取人は、いまのところ一人もいません。
さらにいえば、こうした仕様変更は英語圏では問題にもならないでしょう。影響を受けるのは、日本語など主に東アジア言語のユーザーだと思います。

とはいえ、電子メールは双方向のコミュニケーションが基本のツールです。言語や国による個別事情を度外視して画一的な処理で固定するのは、いかがなものかとは思います。
ユーザーの率直なニーズとしては、言語固有の対策が可能なオプションを設けて、このあたりの問題をコントロールできるようにしてもらえれば、ありがたいとは思います。

ただ、漏れ聞くところによると Thunderbird の開発リソースがますます厳しい状態だとか......。これだけ多様なプラットフォームと言語に対応しているメールクライアントを長年維持・発展させてきたのは驚異的なことだと思いますし、その努力を続けてこられた Mozilla の関係諸氏には最大限の敬意を表したいと思います。
それでも、特定の言語・国であっても現実に不都合を感じる場面が増えるのだとしたら、それはメールクライアントとしてはどうなのか、という疑問は残ります。

[quote="f-angel-mzzj"]※本文にエンコーディングを指定してSubjectが連動しないことは
　それはそれでメッセージ単体の整合性として奇妙に思いますが。[/quote]
おっしゃることは理解できますが、日本語の電子メールを使う場面で、Unicode が使用されるケースが増えているのは事実です。
件名に ISO-2022-JP では取り扱えない文字や記号が含まれている場合、UTF-8 でエンコーディングすることになります。しかし、本文には含まれていないなら、本文は ISO-2022-JP のエンコーディングで十分...ということになります。電子メールの規格としては、エンコード指定は個別に指定できたはずですし......。

件名と本文に含まれる文字や記号の組み合わせによって、Thunderbird がどのような処理をするかの簡単なテストをおこなった結果を、下記のトピックに投稿しました。
よかったら参考にしてみてください。
（参考）・Thunderbird 38.0.1 文字コード
http://forums.mozillazine.jp/viewtopic.php?t=15477&p=55462#p55462

で、個人的な結論としては、
（a）過去の受信メッセージにおけるスレッドペインの文字化けのフォロー
（b）特定の受信環境への配慮としての送信メッセージの作成補助
―― の目的で、しばらくは 31.x 系を手放せないな、と思っています。
（31.x 系と 38.x 系で、別々のプロファイルを使っています。）

解決策ではなく単なる情報でしかありませんが、以上です。役に立たない話だったらすみません。

初めて投稿します。よろしくお願いします。

正常: Thunderbird 31.7.0まで
異常: Thunderbird 38.0.1/38.1.0

Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
Windows7 SP1/x86-32bit環境

＝＝＝＝＝＝
1. MIME形式でないPlain text
2. MIME形式でヘッダに
　Content-Type: text/plain; charset="iso-2022-jp"
　Content-Transfer-Encoding: 7bit
　MIME-Version: 1.0
　の指定がある。

1/2.のいずれかで、かつ本文・Subject:がISO-2022-JPエスケープシーケンス
(BASE64ではなく直接ESC$B,ESC(Bの埋め込みによるプレーンテキスト)で
7bit JISエンコーディングされている。
＝＝＝＝＝＝

フォルダに保存した古いアーカイブや、自動応答メールなどで上記条件に当てはまる
物は、メッセージペインに表示される「件名」が正しく表示されない。

ただし、メッセージペイン以外の部分ではSubjectや本文が正しくデコードされ、
表示されている。

例：
　本来は：【受付完了....
　メッセージペインの表示：□$B!Z<uIU.....

38.0.1で発信時のSubjectエンコーディングがUTF-8に固定された副作用の
enbugでしょうか？
※本文にエンコーディングを指定してSubjectが連動しないことは
　それはそれでメッセージ単体の整合性として奇妙に思いますが。

InterOperabirityとアーカイブの検索に問題があるので、
31.7.0に戻して使用しています。