元記事
↑こちらが元記事になります。事情があり、zennからQiitaに乗り換えました。
追記
Gutenberg、フルサイト編集についての今までとこれから【メリット】
アーカイブ一覧や投稿日一覧などがエディタで操作可能
フルサイト編集では、すべてのページをエディタ上でコントロールすることができます。
例えば特定の文字をループの上に差し込んだり、画像を入れ込んだりすることもエディタ上で操作可能です。
クライアント 
「記事一覧に●●●というテキストを入れたいんですが、、、」
今まで
archive.phpを編集してテキストを挿入、CSSを編集して空白や文字サイズなどを調整する。
→それらのファイルを本番環境にアップロードする。
これから
フルサイト編集の操作方法を理解していれば、クライアント側で対応できる！
クエリーループが便利
記事の途中に関連記事を出したいときに、Gutenbergのブロックを使用すれば、クエリーループを使用して吐き出すことができます。（もちろん、限界はある。）
今まで
この文章の下に、関連の投稿一覧を表示させたいんだけど、できないからとりあえずリンク張っておくしかないか、、、
これから
クエリーループを使用すれば好きな投稿タイプ、カテゴリーの一覧を出すことができる！
ループの概念が理解できていれば、独自テーマのようなカスタマイズができる。【メリット】
ループとGutenbergのブロックの使用方法がわかっていれば、フルサイト編集で独自テーマのようなものも開発できてしまう。
しかも、WordPress6.0からエクスポートができるようになった。
今まで
PHPの知識が十分にないとテーマのカスタマイズが難しい、、、
これから
フルサイト編集で、これまでよりもテーマに依存せずにカスタマイズすることができる。
（Gutenbergに依存します。カスタム投稿を追加するなどのことはできません。）
Gutenberg、フルサイト編集についての今までとこれから【デメリット】
CSSについて
WordPressは、独自のCSSを追加してスタイルを調整するという従来の方法から、theme.jsonだけでCSSを管理する方法に変えることを目標にしている。すべてはGutenbergにコントロールされている。
今まで
Gutenbergの機能を制限すれば、CSSは開発者の自由に決めることができる。
これから
Gutenbergのブロックをほとんど使用することになるので、CSSで調整することが難しくなっていきそう。
GutenbergのCSSは、WordPressのアップデートの度に微妙に調整されることが多いので、アップデートをされた際に、サイトの表示が崩れる可能性がある。そのため、Gutenbergを中心としたサイト構築を進めた際は、アップデートの時に、どの部分のCSSが変更されたかを確認して、該当のブロックが使用されている記事の確認をする必要がある。
デザインの表現が難しい。
Gutenbergが吐き出すブロックに合わせてパーツを作成する必要があるので、CSSで調整するには普段の3倍くらいの時間がかかる。
今まで
テンプレートで好きな場所にループを使えば良くて、class名も自分で調整できるから、デザイン通りに表現するのはそんなに難しくない！
これから
すべてがGutenbergに支配されているので、Gutenbergが吐き出すCSSを元にスタイリングをする必要があるから、今まで通りには難しそうだ。
自由度を高くするためには
GutenbergのブロックをReactを使用して自分で組み立ててそれを使ってテーマを作るのが一番自由度が高く作れる（ですが、メンテナンスがめちゃくちゃ大変、、、）
提案
フルサイト編集ができるテーマをクライアントに提案する場合、以下のような事項を検討すべきです。
- フルサイト編集でクライアントが誤って操作をした際に、サイトが崩れた時の対応
- フルサイト編集の説明（クライアントで頑張って覚えてもらうしかない）
- WordPressのバージョンアップ時のCSS崩れ調査
- テスト環境と本番環境の同期をどうするか
（むしろ、テスト環境というものがないことが前提となっていそう。。。WP STAGINGなどのプラグインを使用したテスト環境で運用していくのがいいのかもしれません。）
結論
フルサイト編集に関しては、もう少し様子を見ようと思います。
React使用してブロック開発も面白そうなのですが、工数がかなりかかりそうです。
※Advanced Custom Fields Proを使用したブロック開発が一番手軽でなおかつ自由度があるので、そちらの記事も後ほど掲載します。