詳しい返信ありがとうございます。
>Ver3.4.0 で検証したところ読み込み時間が 3,4分 から 約40秒 まで減りました。
そんなに減りましたか。
多くて30%くらいの高速化だと思っていたので、意外に効果があったようでよかったです。
>再現可能なプロジェクト
もし、プロジェクトを送っていただくのが難しいようでしたら
Utage\Scripts\ADV\Command\AdvCommandParser.cs の CreateCommand内を以下のように書き換えてみてください。
Profiler.BeginSample("CreateCommandDefault" + id); とすることで、コマンドの種類別にオブジェクト生成のプロファイルができるようになります。
(ただこれをしてしまうと、文字列の連結を毎回行うことになるので、これ自体が負荷になる可能性があり、正規版のコードには入れていません。手動で書き換えたのちに戻してください。)

そうすると、プロファイラーの結果はこのように、コマンドの種類別に計測結果が得られると思います。
何か特定のコマンドの作成がボトルネックになっているのであれば、そこを対策すれば解決するかもしれません。

たとえば、スクショのサンプルですと「CreateCommandDefault Parameter」が一番重いですが、これはフラグ操作などで使うParamコマンドです。
Paramコマンドは文字列で書かれた数式を、プログラムで解析しているため重い処理になっています。
ただ、これは必ずしもこのタイミングで行う必要がなく、少し工夫すれば処理を分散させることができます。
ボトルネックになっている部分がわかれば対策がしやすくなるので、上記のようなプロファイラーのスクリーンショットなどをいただければと思います。
AssetBundleの問題やインポート時間の問題は、Unity開発で昔から問題になっている部分で、Unity公式でないと解決が難しそうです。
おっしゃる通り、ビルド用のプロジェクトを作るのが一番効果がありそうです。
もしくは・・・
・本来のプロジェクトAを作る。ここにはリソースを含めない。
・AssetBundleを作成するプロジェクトBを別途用意して、出力先にプロジェクトAのStreamingAssets以下を指定する
という、AssetBundle作成用のプロジェクトBを別途用意するパターンが考えられます。
StreamingAssets以下に置いたファイルは、インポートの対象とならないため、ビルド時の再インポートの問題も回避できます。
または、AssetBundleを使う目的がファイルサイズの削減なのであれば、
AssetBundleは作成せずに、Resourcesのみを使うのも良いかもしれません。
Resourcesを使った場合にファイルサイズが増えるのは、圧縮がかからないためなのですが、
apkファイルの場合(iPhoneの場合はストアにアップロード後)全体に圧縮がかかるため、そこまで違いはないという話も聞いています。
また、最近のUnityであれば、PC向の出力であっても、全体に圧縮をかけるエディタ拡張方法があります。
ただ、実際にどのくらい違いがでるかは私もわからないです。
> (IPreprocessBuild, IPostprocessBuild での移動も時間がかかり断念)
情報ありがとうございます。私のほうで対策できるとしたら、この部分のエディタ拡張をするくらいしかないと思っていたのですが、
あまり効果が見込めそうにないのと、ビルド環境はやはりプロジェクト個別に環境を合わせるべきだと思い手を出していませんでした。
>Resource Converter
おそらく全てのリソースをロードせざるをえないせいだと思います。
Renameも同様にメモリが足りないなどで、なんらかの原因がありそうです。
Unity自体の仕様の可能性があり、ちょっと対策の目途が立ちません。
この辺は宴ではなく、Unityそのものの問題である可能性があり、
大手の開発環境では、ビルド専任のエンジニアが対策を行っているケースもあると聞いています。
根本的にResourcesもAssetBundleも問題が多いもので、昔からUnity公式でも問題視されていました。
Unityは現在それに代わる新しい仕組みを開発中です。
ただ、もうすぐ正式リリースではあるのですが、宴がこの仕組みに対応する予定はまだないです。
というのも、上記のビルド時間の問題が解決するわけではなさそうなのと、
新しい仕組みはUnity公式の不具合が必ず多発するので、私個人ではサポートできないためです。
もしそちらに移行するのであれば、一応こちらにファイルマネージャー自体をカスタムする手法をまとめてありますので、参考にしてください。