◆ ツールによっては設定されて自動で使われてる
◆ 自分で設定して意図的に使ったことない
◆ 重いライブラリをあれこれ入れなければ分割必要なサイズになることがまずない
◆ ES Modules を直接使うと最初から分割済みなのでいらない
◆ 今後も使わなくて良さそうだった

CRA を使った React や Nuxt だと自動で Webpack の設定をしてくれているので ユーザコードとライブラリコードが分かれたり Code Split 機能が使われています
そういえば自分では使ったことないと思いましたが 考えてみるとあまり必要になることもない気がしました

開発中は ライブラリが別に分かれていると 変更したときのリビルドが速そうですが ライブラリ込みでも遅延を感じるほどの大きさになってません
あれこれライブラリ入れたくないので 必要最低限にしてますし
あと個人的に自動でリロードするのがあまり好きじゃなくて手動でリロードしたタイミングでリロードするので多少遅くても困らないことが多めです

公開後のことを考えても minify + gzip まですれば全体を 1 つの JavaScript にしても 1MB を超えることはそんなにないと思います
大きくても 10MB を超えたことはまずないです
1 ページの画像ファイルだけで数百 KB ~ 数 MB が当たり前のようにダウンロードされる時代にスクリプトファイル全体で数 MB くらい大した問題には思えません
特に SPA なら初回がちょっと遅いだけで 一度開けばその後のナビゲーションは高速ですし キャッシュしておけばリロードしても再ダウンロード不要です

実際 JavaScript はスクリプトなわけで基本はボタンを押したときなどイベント時の「処理」や DOM を作るための構造くらいのはずです
例えばこのブログを SPA にしたとしても 記事リストや記事本文やカテゴリみたいな「コンテンツ」は含まれません
こういうコンテンツは fetch で API から JSON などで受け取ったりです
そう考えると 1MB を超えることすら難しく思います

そもそも Code Split がでてくるのは Webpack などでバンドルするからの話で ES Modules を直接使ってると最初から分割済みなので不要なものです
Webpack 前提なフレームワークを使うときくらいしか関係ない上に そういうときでも有名どころのツールを使っていれば Webpack の設定まで管理してくれてるので 自分でこのあたりの設定を触る必要があることはほぼなさそうです