参考になるか分かりませんが、、、
いずれもtaskを継承したテーブルであり、フィールドとしてはどちらも実態はtask.stateの様です。
以下の記事を見る限りsc_requestとsc_req_itemは1:Nの関係となるため、
ここから類推するに用途としてはsc_req_item.stateが各要求アイテムの状態管理、
sc_request.stateは要求単位の状態管理に分類されると思います。
一般的な考えに基づけば子アイテムの状態を全て処理してから親アイテムの状態を変更するのが適切かなと思いますが、Servicenow側で勝手にやってくれる部分もあると思うので、厳密に設計したいのなら後述する様に全てのトリガースクリプトをトレースすることになるかもです。（もしかしたらちょうどよい公開記事などあるかも知れませんが、、、）
※普通に考えるなら親が子を管理する関係上、親を先に変更したのちに子を変更すると不整合が生じるか再計算が生じるのかなと
https://www.servicenow.com/docs/ja-JP/bundle/xanadu-it-service-management/page/product/planning-and-...
また、sc_request.stateはフォームエレメントに含まれていない事から、内部的に状態管理するためのもの（＝ユーザやスクリプトによる入力を想定していない）と思います。
全て洗い出してはいないですが、以下の様なビジネスルールでハンドリングされている様です。
■sc_request（①に係る一部回答）
request closure
→SNCパッケージ内機能のためソースは読めませんでしたが、cancelRelatedRecords()という名前を見る限りでは、closed_cancelledがセットされた場合、関連する子アイテムをキャンセルしてくれそうです。
Set Request State
→approvalの承認結果に応じてstateとrequest_stateを決定する
■sc_req_item（②に係る一部回答）
Reduce request price - item change
→価格の再計算処理。stateの変更トリガーでも動作。
reject approval on closed incomplete
→stateに4がセットされるとapprovalはrejectedとなる
Close Tasks Due to Cancellations
→stateがRequest Cancelledに遷移すると関連するすべてのsc_task.stateを4に変更する
※厳密にどの様なふるまいをするかはこれらビジネスルールや他トリガー（あるなら、EventQueueのAction等）をトレースする必要があります。
![[sc_request]テーブルの[state].png](/community/image/serverpage/image-id/404801iCEDE8BA4F7E9DF6E/image-size/medium?v=v2&px=400 "[sc_request]テーブルの[state].png")
![[sc_req_item]テーブルの[state].png](/community/image/serverpage/image-id/404802i8734372F3F2D165C/image-size/medium?v=v2&px=400 "[sc_req_item]テーブルの[state].png")
