一般的なWEBフレームワーク全てに言えることだとは思いますが、基本的には手間を省くために使うんですけどね。禅問答のようですが。
画面とバッチが分離しているようなタイプのWEBアプリの設計は、基本設計がクライアントサーバー型と変わっていないんです。
そこにどんな問題があるかというと、一番大きなものとしてはクライアント側とサーバー側の通信を気にしないといけないですよね。クライアントとサーバーが分離しているために、何か発生した場合にどこに問題があるのか調査するのに手間取ります。
そもそも動かすためだけでもいろいろとサーバー側のセットアップが必要になります。
画面からサーバー側のアプリケーション(バッチ処理など)をキックするだけでも結構セキュリティ面などに引っかかって動かなかったりしますよ。
まあ慣れればそこまでの負荷ではないのですが、そういう手間も省きたいということで出てきたのがDjango等のWEBアプリケーションのためのフレームワークですね。
ひとつの開発環境でひとつの言語で画面と処理がひとまとめに開発できて、本番環境での運用開始もWEBサーバーにデプロイするだけ。
一度使ってみると分かりますが非常に便利なんですよ。クライアントサーバー型で気にしていた色々なことを、一気に気にしなくてよくなります。
そういう背景があって流行っているわけです。
このあたりが一般的な回答ということになるでしょうけれども、ただしこういうフレームワークもあくまで必要に応じて使うものです。
例えば現状の「Pythonのプログラム」が既に100近くサーバーで動いていて、それを全てDjangoで再構築するというのであればちょっと大変でしょうね。
そのような背景があるのであれば、ryounaman19さんの仰る「手間が10分の1くらいになる」という主張もよく分かりますし、私がそういうシステムを再構築するのであっても画面のみを作ってサーバー側のPythonのプログラムをキックするような構成を一番に検討します。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。