SIでその辺りを求められるのは顧客側の企業からということでしょうか？それなら、ランクが高いエンジニアなら求められるかもなと思いました

個人的には私も②あたりできれば良いんじゃないかなと（技術を追求し過ぎて開発工数やインフラコストを無駄に浪費しない感覚があってほしい）

ビジネスと一口に言っても、色々あるかなと思いました。おそらく、以下の最初の開発業務における部分を指してのことだと思いますが（その中では、年次・立場により②までか③までか変わるかと）。

・開発業務におけるエンジアリング以外の部分

・ERPが司るような会計・ロジ・人事のような基幹業務

・CRM/SFA/MAが司る営業、販売、顧客関係構築、マーケティング

・経営者やビジネス開発職種が司る戦略、M&A、各種アライアンス

③を求められる場合開発はできませんけどそれはいいんですよね？って感じです。

ソフトウェアエンジニア単体で十分価値を産めるようなビジネスモデルではないのに流行だからと内製しようとしてる阿保な組織がやりがちだと思います🤪

まあ責任自体はRACIチャートなどでAとRで分けつつ、ある程度は別領域（今回ならビジネス）の解像度も”あったほうがいい”というのが現実かなと思いました。ビジネスサイドのRやましてやAを開発サイドのエンジニアが担うのは明らかに責務権限の破綻ですね。チャートにすれば一目で破綻が見えると思います。

逆にいうと、「どれくらい」の答えとしては、技術のことは一切さっぱりだし知りたくもないし解像度？知らんがな。というビジネスサイドの人と働きたいかと言われるとそんなことはない。といった意味合いかと。