Mastodon v3.3.0では、リモートアカウントの情報を相手方サーバに確認しに行ってサーバが410 Goneを返してきた場合、アカウントの削除ワーカーを起動するようになりました。
410 Goneを返してくるのは、サーバ全体が閉鎖され、管理者が意図的に410 Goneを返すように設定しているケースもありますが、
通常は、取得しようとしたアカウントが削除され、もう存在しない場合です。
なお、相手方のサーバがMastodon v3.3.0以降の場合は、アカウント削除を行って30日以内の場合は、410 Goneではなく、空のプロフィール情報を返すように変更になっています。（管理者は、30日を待たずに手動で完全削除できます）
この30日の猶予期間によって、アカウントのサスペンドを取り消すことが可能となっています。
なお、これまでは410 Goneを受け取っても特に何もしませんでした。（管理者がtootctl accounts cullを実行した場合に削除されました）
今後は、削除されたアカウントは実行時に自然に削除されていくことになります。
既に存在しないアカウント情報が自動的に掃除されていくのは基本的に良いコトなんですが、割としんどい面もあります。
何しろ、何らかのタイミングで参照した時に発動するので、突然Sidekiqにアカウント削除の負荷がどーんと来ます。
これまでたくさん投稿をしてきたアカウントが削除されると凄いですよ！
Mastodon v3.3.0で410を返すアカウントを自主的に削除する挙動は、削除漏れを回収（正常化）する機能です。
410を返してくるということはアカウントが既に元の利用者により削除されているということで、まだ手元に残っているのは正しく同期がとれていない、削除漏れとなります。
本来、リモートに残っていてはいけないものです。
突然アカウント削除の負荷がかかるのはつらいところですが、リモートの誰かがアカウント削除した際にも削除リクエストされますから、同じように負荷がかかります。
何か問題があるとすれば、あらゆるアクセスに410を返すサーバです。サーバ閉鎖時の手順として知られていますが、意味の理解が必要です。
積極的に、もう存在しない、削除済みのリソースであることを対外的に示すことになります。つまり実質self-destructと同義です。Fediverseから痕跡を消す意思表示となります。
なお、410を返さず、単にアクセスできなくなったサーバは、7日間配送に失敗した時点で、単に配送不可能なサーバとして記録されます。
この場合、アカウントやコンテンツは削除されません。
もう一つ、アカウントの削除リクエストを取りこぼすケースもあります。
サーバがおちていたり、不調だったり、ひょっとしたら更新に失敗してDBをロールバックしたり……。どこのサーバでもありそうなことですよね。
tootctl accounts cull で対応できますが、自動化されてなければ、そうそう実行しないですよね。
具体的な事例として、mstdn.jpの削除不具合があります。
mstdn.jpは、アカウントを削除する処理が不完全で、長らく、連合先にアカウント削除のリクエストが飛んでいません。（たいぶ今もなおっていません）
そのため、これまではリモートのサーバにデータが残り続けていました。
これは、アカウントを削除して存在を消したかった人にとっては非常に困った問題で、Fediverse中の各サーバ管理者に削除をお願いしてまわるしかありませんでした。
v3.3.0では、アカウントや投稿を参照する際にアカウント情報をmstdn.jpにフェッチしにいったタイミングで410が返ってくるため、自動的に自主的に削除処理を行って正常な状態に回復します。