について。かつては、bundle packageという名称であったし、ドキュメントも https://bundler.io/v2.0/man/bundle-package.1.html に残されている（当該Bundlerバージョンは既にdeprecated＝メンテナンスされていない）。両者はほぼ同じことを実現するため、Bundler 2.1くらいに完全に統合された。し、2.3中盤ではそれがrubygems/rubygems#5785において少しだけ分かりやすくされた。
私自身はこれまでほぼ使う場面がなかったのにドキュメントをメンテナンスすることになったしメンテナンスしているのだが、どういう場合に活用するのだろう。活用ケースによって、どちらのサブコマンド名が一般的なのか分かるのかもしれないので、質問してみたい。
例えば、npm ci https://docs.npmjs.com/cli/v8/commands/npm-ci では ci が標準のサブコマンドになっていて、 clean-install はエイリアス扱いである。
見つけたケース
今年2Qでは3番目のコントリビュータ *1 であった、世界No.3 (*2) の（OSS）RailsアプリケーションであるForem (dev.toの実装) では2020年くらいからこれを導入している。
経緯としては、当時のForem Core teamであった@jdossによる https://github.com/forem/forem/pull/8066 で導入されたらしい（今知った）。
開発者体験の観点で行くと、追加・アップデートにおいては手間が増えたり、Git repoサイズも肥大化してしまうデメリットばかりが先行してメリットを感じられなかった。運用目線でも、RubyGemsパッケージレジストリー（https://rubygems.org）が突然死んでしまったり、利用していたgemのバージョンがyankされたりしまった場合にわずかなメリットはあるかもしれないが、CIのキャッシュレイヤーに閉じ込めておけば十分だと感じていた。CIのキャッシュレイヤーが適切に機能していることは必須要件になってしまうが。
あり得るのはCI環境（CD環境が分離されていない場合はCD環境を含む）がair-gappedである場合だが、開発者環境はair-gappedではないならあまり意味がないような気がしたのだが、どうだろう。
そもそもBundler 3では...
先のPRの説明を見返してみると、
cache_all(BUNDLE_CACHE_ALL): Cache all gems, including path and git gems. This needs to be explicitly configured on bundler 1 and bundler 2, but will be the default on bundler 3.
-- https://bundler.io/v2.3/man/bundle-config.1.html
ということらしく、いつ出るか分からない（pre-Bundler 2時点でのメジャーアップデート計画と比較してだいぶ長期間のメジャーアップデートになりそう）Bundler 3では「デフォルトになる」らしい（と言っても、デフォルトで true になるとは書いていないので、かなり曖昧な表記でがあるが）。有効になったタイミングでは、 vendor/cache を .gitignore に追加した人が続出しそうに思える。
まとめ
bundle package を主に bundle cache を従にすべきじゃないかという考えの前提で、この質問を書き始めたのだが、本当に bundle config cache_all true を標準にしていきたいなら、今のままにするのがよさそうに思えてきた。ということで、これはそれに至る思考メモ（とhttps://www.google.com/search?q=bundle+packageのSEO）でした。
Bundler 3で予定されている変更点は https://qiita.com/jnchito/items/d3257a5f46f4f1aee200 を参考にするとよさそうです。
注記
*1
*2
Discourse (36.2k stars), GitLab (Community Edition) (23.0k stars)についで19.5k stars。rails本体およびdeviseを除く。