結論から言うと

「DataBaseから取得するだけでは終わらないサーバー処理」をするのがData Actionの役割。
「(Client Actionから）Server/Service Actionを実行する」方法でも代用可能だが、Data Actionにすると、画面表示時に自動で取得開始してくれるので、使い分けをする。

画面のイベントでServer Actionを呼ぶことの問題点

画面のイベントというのは、On InitializeやOn Readyのように、画面のライフサイクルで自動発生するイベントのこと。その中でも、On InitializeやOn Readyは画面の初期処理としてサーバーからデータを取得するのに都合が良いものに見える。

しかし、On InitializeやOn Readyが終わらないと画面の描画が始まらないため、サーバーにアクセスするような処理時間のかかる処理を行うのは非推奨となっている（その間、ユーザーを待たせてしまうため）。
パフォーマンスの提案に関する警告の「'<OnInitialize action | OnReady action>' contains accesses to the local」で始まる項を参照。

この代替としてはData Actionが適している。Data ActionのOutput Parameterか、それをOn After Fetchで後処理を行ってLocal Variableに格納したものを利用するようにWidgetのプロパティを設定しておくとよい。

利用例

外部サービスの値を取得する

RESTやSOAPなど、外部のデータソースからサービス経由でデータを取得したい場合。
Aggregateでは取得できず、Data Actionを使うことがある。

DBで取得した結果を後処理する

Aggregateで取得した結果によって、処理を分岐して別のAggregateを取得したり複雑な計算をサーバー側でするような場合。
例：顧客の情報を外部ソースから取得するとして。顧客をまずAggregateで取得、更にその規模によって大企業はCRM、それ以外はSaaSのサービスに問い合わせないといけない場合など。

On After Fetchという方法もある

単にDBから取得した値に後処理したいのなら、AggregateのOn After Fetchのイベントハンドラで処理する手もある。クライアントで解決するならこっちの方法もあり。

ただし、後処理がサーバーでないと行えない（外部サービスを呼ぶ、Server Actionで作られた部品を使うなど）場合はData Actionにしたほうが通信回数が減ってよい。

サイトプロパティを取得する

クライアント側ではSite Propertyを直接操作できないので、Data ActionのOutput Parameterに編集するしておいて、画面側で利用できるようにする。