はじめに
Thunderbird のメッセージ格納形式である mbox 形式と maildir 形式の特徴、管理機能である「フォルダーを修復」と「フォルダーを最適化」の役割の違い、それらの組み合わせに関するいくつかを、ざっくりとですがまとめておこうと思います。
そう思い立った理由は、これまでも知り合いの Thunderbird ユーザーから maildir 形式に関する質問を受けたことはあったのですが、今年 4 月以降に数人から同じような質問を受けたので、Thunderbird ユーザーの中で関心が高まっているのかな、と考えたことがひとつ。すでに maildir 形式を使っているユーザーからは、「フォルダーを修復」と「フォルダーを最適化」についての質問を受けたことが過去に何回かあったので、その点にも問題意識が向きました。
ご承知の方にはいまさらな内容ですが、それぞれの関係性に注目してまとめておくことにも意味はあろうかと思いますので、このフォーラムのスペースを使わせていただきますことをご容赦ください。
以下、メニュー名や設定名などは、現時点での現役バージョンである Thunderbird 60.x 系の Windows 向け日本語版の表記を基準にしています。

--　おもな内容　-----------------------------------------
（1）全体の概要
（2）メッセージ格納形式の概要
　（2-1）mbox 形式
　（2-2）maildir 形式

（3）管理機能の概要
　（3-1）フォルダーを修復
　（3-2）フォルダーを最適化
---------------------------------------------------------

（1）全体の概要
Thunderbird で送受信したメール（メッセージ）の保存（格納）形式の違いが、mbox か maildir かの違いです。
現在の Thunderbird は mbox 形式が初期設定ですが、任意に maildir 形式に切り替えることができます。それぞれの形式には特徴があり、利点もあれば弱点もあります。
そして、保存メールを適切に管理するため、あるいは問題改善のため、「フォルダーを修復」や「フォルダーを最適化」の機能があります。

全体の関係性をおおまかに示すと、次のようになります。（表は等幅フォントで最適化）
┌──────┬────────┬──────────
│＼＼＼＼＼＼│フォルダーを修復│フォルダーを最適化
├──────┼────────┼──────────
│mbox 形式 　│実行する意味あり│実行する意味あり
├──────┼────────┼──────────
│maildir 形式│実行する意味あり│実行は不要・無意味
└──────┴────────┴──────────

（2）メッセージ格納形式の概要

（2-1）mbox 形式
Thunderbird 上の１フォルダーに存在するメール群を、システム上（プロファイル内）では１ファイルで保存する形式です。
例えば、Thunderbird 上の [受信トレイ] に 100 件のメールが存在するとき、プロファイル内の実体ファイルである Inbox ファイル（拡張子なし）には、100 件分のメールデータがまとめて保存されています。
送受信した個々のメールデータを散逸させず一元管理するのには適していますが、実体ファイルの肥大化が起こりやすいのが弱点です。実体が１ファイルだけなのでプロファイル内の構造はシンプルですが、実体ファイルが破損すればすべての保存メールを一気に失う危険もあります。

（2-2）maildir 形式
Thunderbird 上の１フォルダーに保存されているメール群を、システム上（プロファイル内）でも１メール１ファイルで保存する形式です。
このファイルは eml 形式であり、Thunderbird から [メッセージを保存] を実行したとき保存されるファイルと実質的に同じフォーマットです。
例えば、Thunderbird 上の [受信トレイ] に 100 件のメールが存在するとき、プロファイル内の実体フォルダーである Inbox フォルダー配下（Inbox\cur\ 内）には、メールごとの 100 個のファイルが保存されています。
１メール１ファイルなので、mbox 形式おける実体ファイルの肥大化のような心配はありません。一蓮托生的なデータ消失も起り難いです（皆無とはいいません）。バックアップやメールデータのマージを、増減のあったファイル群の処理だけで実行できるのも利点です。
半面、受信したメールの数だけファイルが存在するので、[受信トレイ] に 5 万件のメールがあれば、実体フォルダー内にも 5 万個のファイルが存在します。当然、プロファイル内の構造もファイル数に応じて複雑になり、要約情報の管理が煩雑化します。プロファイルを直接手動操作するメンテナンスやトラブルシューティングでは、個々のファイルが散逸しないよう十分な注意が必要です。

（補足）
ひとつのアカウント内に mbox 形式のフォルダーと maildir 形式のフォルダーを混在させることはできません。あくまで、アカウント単位でどちらの形式を使うか、です。

（maildir 形式についての現状における注意点）
maildir 形式は、Thunderbird 38 から実装が始まりました。最初期のころは実際に試してみてもトラブルが多く、とても常用できるレベルとは思えませんでした。この時点で Thunderbird の開発は Firefox の ESR 版に準じたペースになっていましたから、メジャーバージョンごとの大きな仕様変更はほぼ１年に１回というゆっくりしたペースです（38 -> 45 -> 52 -> 60 -> (68) ……）。

致命的なトラブルもあった最初期以降、mbox 形式を使うか、maildir 形式を使うかは、[オプション] -> [詳細] -> [一般] -> [高度な設定] にある [新しいアカウントのメッセージ格納形式] を切り替え、そのあと新規に作成したアカウントは選択した形式にできる機能として継続してきました。
Thunderbird 60.0 では、既存のアカウントのメッセージ格納形式を変換する機能が搭載されました。
それなりに進歩しているわけですが、現時点ではまだ、実験的 (Experimental) な機能の域を出ないものであることに注意してください。
（一例）
・Thunderbird 60 の新機能 | Thunderbird ヘルプ
support.mozilla.org/ja/kb/new-thunderbird-60#w_maildir-aggaeeoeeacl

"実験的" という位置付けとも相まって、この機能を使うには、設定エディター (about:config) から mail.store_conversion_enabled の値（初期値 false）を true に変更する必要があります。
（補足）
バージョン 68 がナイトリーの 68.0a1 だったころ、この初期値が true になっていたことがありますが、あくまでナイトリー版での積極的な実験の一環だったようで、ベータ版（現時点の最新は 68.0b5）では初期値 false に変更されています。この分なら、68 の正式リリース版も false のままなんじゃないでしょうか。つまり、デフォルトでは無効化された "実験的機能" の状態が続く可能性が高そうです。

（注意点）
この変換機能で形式を切り替えたとき、既存形式のデータはそのまま残して、新たに選択した形式のデータ群が追加構築される点に注意してください。
例えば、mbox 形式で設定していたアカウントを maildir 形式に変換した場合、元が <accountName> フォルダー内に保存されていたとしたら、変換後のメールデータは新しく生成された <accountName-maildir> フォルダー内に保存されます。変換後のメールの送受信結果は <accountName-maildir> 内に保存されますが、変換時点のデータを持つ <accountName> フォルダーはそのまま残されます。つまり、変換時点までのメールデータは同じ内容が重複して存在することになります。
（将来的にどうなるかはわかりませんが、おそらく変換に失敗した場合に備えた保険的な動作なのだと思われます。）
また、<accountName-maildir> で運用したあと、再度 mbox 形式に変換した場合、元の <accountName> フォルダーではなく、新たな <accountName-mbox> フォルダーに変換後のデータが保存されます。変換前のデータがそのまま保存されるのは上記と同様なので、変換前のメールデータをユーザーが意識的に処理しない限り、二重、三重に存在するメール群が出てきます。
結果論ですが、現状ではユーザーの管理意識の外に重要なメールデータがそのまま残る場合も出てきそうです。ユーザーから見て Thunderbird 上で完全に抹消したつもりのメールが、保険的に維持された場所に残っていることがありえますから、とくに企業ユーザーは注意してください。

いちおう、maildir 形式も順当に進化していると見て差し支えないと思いますが、それでもまだ、mbox 形式と対等な選択肢にはなりきれていないようです。現状で maildir 形式を使うときは、その点に注意を払ってください。

（長くなるので、続きは別途投稿します。）

_________________
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

（上記の続きです。）

（3）管理機能の概要

（3-1）フォルダーを修復
mbox 形式と maildir 形式の両方に影響します。
（厳密には、"フォルダー内情報の修復" ＝ フォルダーに含まれるメールの要約情報の再構築、といえる内容です。）

どちらの形式も、Thunderbird のフォルダーペインで任意のフォルダーを選択し、その中のメール一覧をスレッドペインに表示するとき、要約ファイル（拡張子 msf ／インデックスファイルとも呼ばれる）が使われます。要約ファイルは、実体ファイル／フォルダーの変化を反映して、随時、自動的に更新されます。

"実体" と "要約" の間に狂いが生じると、削除したはずのメールが表示されたり、存在するはずのメールが表示されなかったり、スレッドペインのメール一覧がおかしくなり、個々のメールの移動や削除などの操作が正常におこなえなくなります。
このようなとき、その時点でプロファイル内にある実体ファイル／フォルダーの現状を読み込み直し、要約ファイルを強制的に再構築するのが、「フォルダーを修復」です。

例えば、[受信トレイ] に対して「フォルダーを修復」を実行したとき、
mbox 形式であれば、その時点の Inbox ファイル（拡張子なし）の情報をもとに、Inbox.msf が再構築されます。
maildir 形式であれば、その時点の Inbox フォルダー配下（Inbox\cur\ 内）に存在するファイル群の在り様をふまえ、Inbox.msf が再構築されます。
（注意）
万一、実体ファイル／フォルダーの内容そのものが欠落・破損していたら、その実情のままに要約情報が再構築されるか、再構築自体に失敗するかもしれません。
実体ファイル／フォルダーの内容から要約ファイル（*.msf）を再構築できますが、逆は絶対にできません。トラブル時のメールデータの復旧やプロファイルの移行では、実体ファイル／フォルダーを最重視してください。

mbox 形式と maildir 形式では、要約ファイルの働きは同じですが、実体ファイル／フォルダーとの関係性が異なります。
そのため、運用実態に左右されるという条件付きですが、maildir 形式において「フォルダーを修復」の実行頻度が増えるケースがあります。
例えば、あるアカウントの [受信トレイ] に着目すると、

mbox 形式では、実体ファイルである Inbox ファイル（拡張子なし）の変化に応じて、Inbox.msf が更新されます。これは「１対１」の関係です。
Inbox ファイルの肥大化やそれにともなうメールデータ消失などのリスクは maildir 形式より大きいですが、フォルダー内のメール群を一括管理する観点からは、Inbox ファイル１つを監視していればいいので、Inbox.msf の更新もシンプルです。

maildir 形式では、実体フォルダー内にある個々のメールファイルの変化に応じて、Inbox.msf が更新されます。これは「多対１」の関係です。
[受信トレイ] に存在するメールの件数と同じファイル数が Inbox フォルダー配下にあるため、複数ファイルの変化の反映として Inbox.msf を更新しなければなりません。
Thunderbird 上で（つまり Thunderbird の管理下で）メールの受信、移動、削除などをおこなう分には、Inbox.msf の更新もそのつどおこなわれますが、Inbox フォルダー内の個々のメールファイルが Thunderbird 以外から変更された場合(*)、Inbox.msf に狂いが生じやすくなり、「フォルダーを修復」を手動実行しなければならない頻度がけっこう増えることがあります。
　(*) ウィルス対策ソフトやシステムクリーニングソフトによる個々のファイルへの干渉、
　　バックアップソフトによる同期・ミラーリングなど。

とくに、maildir 形式の利点を活かし、複数の環境間でメールファイルを同期して使うような方法を常用したとき、実行条件やそれぞれの環境の Thunderbird の状態によっては、要約ファイルの更新が適正におこなわれない場面が増えることがあり、それを修復するため手動で「フォルダーを修復」を実行する場面も増えるということです。
これを逆用すれば、Thunderbird の起動中に、プロファイルの Inbox フォルダー内にバックアップからいくつかのメールファイルを書き戻したとしても、Thunderbird 上で「フォルダーを修復」を手動実行すれば、プロファイルの変化を即座に要約情報に反映させることができます。（そのような使い方は、積極的にはお勧めしませんけど...。）

（3-2）フォルダーを最適化
mbox 形式だけに影響を与える機能です。
（厳密には、"フォルダーの実体ファイルの最適化" ＝ フォルダーの実体ファイル内のクリーンアップ、といえる内容です。）

mbox 形式では、メールの削除や移動をおこなったとき、実体ファイルに保存されている当該データには削除や移動のフラグが付けられます。この変化に応じて、フラグが付いたデータは、要約ファイル（msf）からは削除されますので、スレッドペインの一覧表示から消えます。
しかし、実体ファイル内には当該データが（不可視化されたまま）残っています。この削除・移動フラグがついたまま実体ファイル内に残っているデータを完全に消去するのが「フォルダーを最適化」です。

「フォルダーを修復」が要約ファイルに作用するのに対し、「フォルダーを最適化」は実体ファイルに作用します。
したがって、単一の実体ファイルを持たない maildir 形式ではまったく不必要な操作です。maildir 形式では、メールの削除や移動は実体フォルダー内の対象ファイルの削除・移動として即時実行され、その結果が要約ファイルにも反映されます。

すでに要約ファイルが正しく削除・移動フラグを反映していれば、「フォルダーを最適化」によって実体ファイルからフラグ付きデータが消去されたからといって、要約ファイルの内容が変化することは基本的になく、スレッドペインの一覧表示にも変化はありません。
もし要約ファイルに実体ファイルの情報が正しく反映されていないときは、最適化された実体ファイルの内容に応じて、通常の情報処理の一環で要約ファイルも更新されます。メンテナンス的には、「フォルダーを最適化」のあとに必ず「フォルダーを修復」を手動実行して、"実体" と "要約" の関係を完全にそろえておく、という考え方もあるようです。

標準状態の Thunderbird では、[オプション] -> [詳細] -> [ネットワークとディスク領域] -> [ディスク領域] -> [ディスク領域を合計 <20> MB 以上節約できるときはフォルダーを最適化する] が有効になっていて、20 MB が初期値です。
これにより、mbox 形式で設定したアカウントにおいて、削除・移動フラグの付いたデータが当該容量を超えると、[最適化] を促すダイアログが自動的に表示されるようになり、ユーザーが許可すると最適化が実行されます。
mbox 形式を使うユーザーは、極端な数値でなければ閾値（既定 20 / メガバイト単位）を自由に調整してかまいませんから、この機能は常に有効にしておき、そのつど最適化を実行することをお勧めします。

最適化は、データ消失のリスクに対する慎重さから、重層的な処理をおこないます（詳細略）。
そのため、処理中はバックグラウンドで少々複雑な（≒負荷のかかる）動作をしています。ですが、上記のように数十メガバイト単位でこまめに最適化を実行している限りにおいては、問題が起こることはまずありません。
危険なのは、最適化を回避し続け、ひとつのフォルダーが肥大化して問題が起こり出してから（例えば十数ギガバイトに膨れ上がってから）最適化を実行するケースです。巨大な容量のデータ処理が一気におこなわれることになり、システムのスペックや運用状況によっては極めて大きな負荷を発生させてしまうことがあります。最悪の場合、最適化に失敗してデータを失うこともありえます。
（夏休みの宿題は毎日少しずつやっておくほうがよく、溜めに溜めた宿題を 8 月最後の日に一気にやるのは無理が大きく破綻しやすい、みたいな...。）

長くなりましたが以上です。
間違っている部分の修正、不十分な内容への補足、新たな知見などの追記を歓迎します。


（おことわり）
現在、健康上の制約により不定期な書き込みしかできなくなっています。すぐに応答できない場面がかなり多くなりますことを、ご容赦ください。

_________________
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0