cybozu developers networkより早い、応答ありがとうございます。　
とはいえ、有効な回答は　未だなようです。

まず、質問内容は、ご提案された「１つのアプリ内で入力するフィールド数を減らす」のと等価な、subTableの行数の上限を制限する処理の　実装内容です。
＞kintoneの詳細レコード編集中に、一般利用者に処置を促すことができるような方法（チェックタイミング・イベントやチェック条件等）

当該subTableの行に詰め込むかしれない項目の最大文字数などから　悲観的に概算すると、50行が上限となる程度に　項目数も多いsubTableです。
※だからと言って「kintoneのsubTableの行数は50行以上増やしてはいけない」なんて吹聴したら、当面のアプリの要件も満たせないし、馬鹿にされるでしょう。

また 　これまでに試して駄目だったチェック方法は、subTableのフィールドのchangeイベントハンドラの中で「JSON.stringify(state.record) < 512*1024」というチェック条件で　subtableのデータを含めたレコード長をリジェクトしようとしましたが、チェック条件が緩かったようで、GAIA_WP01エラーになりました。

そこで、当面は「JSON.stringify(state.record) < 256*1024」というチェック条件で、GAIA_WP01エラーとなるのを、kintoneのレコード編集中に抑止しようと考え始めています。

でも、それはGAIA_WP01エラーチェック条件とは異なった条件に成っているであろうことが不満です。
※「勝手な制限を設けるな！　kintoneが受け入れ可能なデータをエラーとするな！」という非難に耐え難いのです。
そうゆう非難をかわすには、 多分、単純なJSON.stringifyではなくて、base64化とかutf8_byte_arrayとかの組み合わせた領域の長さを計って、GAIA_WP01エラーチェック条件と等価にするのが良いのでしょう。

そんな風な　チェック条件として、良さそうな実装は無いでしょうか？

「１つのアプリ内で入力するフィールド数を減らす（２つ以上のアプリを用意する）」ことと「javascriptを利用してテーブル（基本機能）の行数上限を制限する」ことは、等価ではないと思います。

kintoneはノーコードツールでありSaaSであるということ、提供側のタイミングでいつでも仕様が変わるツールである（だからこそ月額費用を払うだけでバージョンアップの恩恵が受けられるのですが）ということを、前提においていただいた方がいいと思います。
kintoneは相当柔軟に作られているツールだと思います。そこまで開発を重ねるのであれば、貴社の場合はスクラッチで作られたほうが良いかもしれません。

また、キンコミもcybozu developers networkも、あくまでユーザー同士のナレッジ共有のコミュニティですから、
貴殿の想定される通りの「有効な」回答が得られるとは限りません。回答している側も無償です。
①サイボウズのサポートセンターにご質問する
②サポートセンターから思うような回答が得られなければ、kintoneにはパートナー企業が山ほどいますので、対応してくれるパートナーを探す
ことをおすすめします。