世間的に、Asia/Tokyoは+09:00とまったく同義だと取り扱われているのではないかと思います。そうですよね、常に日本時間は世界標準時+9時間です。なにしろ日本には夏時間がありませんからね。

夏時間がない、それが問題です。覚えていらっしゃいますでしょうか2020年の夏、オリンピックの試合を涼しい時間にやるためという目的でいきなりその年からの夏時間（しかも2時間）導入が真面目に検討されたことがあったのを。国の制度は変わりうるのです。Asia/Tokyoが+09:00と同義なのは今のことであって、将来どうなるかはわからないのですよね。

Asia/Tokyoと指定すると

OSやミドルウェア、言語処理系を適正にアップデートし続ける限りは、国の制度の変化にも追従し続けることができます。つまり、Asia/Tokyoと書いていたなら夏の間は世界標準時+10時間だったり+11時間だったりで変換されるようになるはずです。

Asia/Tokyo指定が特に適しているのは、UI向けの変換です。

ソフトウェア内部では、日付時刻はタイムゾーンによらない絶対時刻で表現していますよね。（⋯ますよね？）　それをユーザーに見せるときはユーザーの所在地による日付時刻に変換して見せるわけですが、それは当然ユーザーの腕時計とあっているべきです。ですから、夏時間に追従している必要があるのです。

+09:00と指定すると

これは標準世界時+9時間を固定しているわけですから、夏時間導入後もまったく変わらない変換になります。

それでは困るのかというと、こうでなくては困る場合というのもあります。主に、分析や日次更新にかかわる処理ですね。

日単位に集計をする場合、夏時間の変わり目で23時間だけの日や25時間ある日が登場するとグラフにおかしな凹凸ができてしまいます。日次更新するようなバッチ処理においても、「24時間より古い未処理データはないはず」のような前提条件が崩れてなにが起こるかわからなくなったりします。

むかしGCPで、無料枠内で使っているはずなのに夏時間の終わる月に1時間超過利用したということで課金が発生してしまったなんて話がありましたね。あれもこれに当たりますね、本来は固定オフセット設定で運用すべきところを地名設定で運用してしまったための問題だと言えます。

外部APIとの変換

外部APIが日本時間で日時を返してくれるのでこちらのプログラム内で処理できるよう絶対時刻に変換するとき、これはAsia/Tokyoと+09:00、どちらが正しいでしょうか？

これは判断しようがないんですよね、外部APIがどちら設定で日本時間時刻を生み出しているのかわからないので。問い合わせてみるのも良いかもしれませんが、正しい答えが得られる保証はありません。（質問の意味さえ理解してもらえるかわかりません）

大変面倒なことではありますが、こちらのプログラム内ではどちらか適当に選択した上で、そこに「このAsia/TokyoはこのAPIの時刻変換と一致しているか不明なので夏時間導入時には要確認」というコメントを残しておくのがベストとなると思います。本当にいざというとき全文検索で全部見つけ出せるよう、定型テキストにしておくのをお勧めしておきます。

まとめ

UIとの変換 ⋯ Asia/Tokyo
外部APIとの変換 ⋯ 適当に決めつつ、適当に決めたことのコメントを
日付区切りを作る処理 ⋯ 要件を検討しつつ、おそらく+09:00が妥当となる場面が多そう