そのほうがTwitter社が楽だからです。以下で解説します。

UserStreamは、各ユーザが一人ひとりコネクションを持ち、送信するデータが発生し次第それぞれにデータを送ります。

UserStreamの場合、Twitterは要求を受ける側となり、基本的に常に待ち構えている必要があります。また、フォロー数が少なかったりしてあまりデータを送信しなくてもいい人とのコネクションもずっと保ち続けなければなりません。

Webhookは、各サードパーティアプリが「こいつらのアカウントに関してなんかあったらここに教えてくれ」というデータの送信先を登録する仕組みになっています。

今度はアプリ側がいつでもTwitterからの連絡を受け取れるようにしなければなりません。Twitterは要求を送信する側となり、連絡すべき何かが発生したときだけ動けばよくなります。フォロー数が少ない人はその人がフォローしてる人の発言があるまで放置できるようになります。UserStreamと比べて、こっちのほうがサーバーの通信能力を使い切れそうですね。

Webhookではアプリ側がいつでも指定の場所でデータを受信できる必要があります。 この仕組みでデータをやり取りするには、各アプリの開発者が自分のアプリ用のサーバーを立てっぱなしにしておく必要があります。ユーザ数の多いアプリの場合、サーバーの維持費がかかりそうですね。

それとは別に、このAPIは1アプリにつき35アカウント以上を登録する場合にはお金がかかります。 一般の人に開放するとなると無料枠では高々35人までしか使えないアプリになってしまうので、無料でアプリを配信するのは難しそうです。

UserStreamには仕組みの面で古くなっていたほかにも、プロモツイートを流し込めないという欠点がありました。現状サードパーティのアプリで使われるぶんにはTwitter社には負荷でしかないので、無料で見るならwebや公式アプリで広告を見てもらい、広告なしのサードパーティアプリを使うならその分のお金は払ってもらう、という意図があるのでしょう。

そういうわけで、アプリ開発者はサーバーを立ててユーザからお金を取る仕組みを作るという大工事をするか、このままUserStreamの廃止に任せて配信を終了するかを迫られている状況になり、少しずつ騒ぎになってきているという事態なのでした。

(2018/3/2 20:00追記)

TwitterにおけるUserStreamの終焉とその代用
廃止予定がなく、代用できるAPIがあったみたいです。 通知が受信できないこと、鍵アカウントを対象に含められないことなど制約はありますが、とりあえずの対策としては有効かもしれません。