ネストが深いリレーションの為、eachのネストが発生するスクリプト（本文中にあり）がでます、こういうのは設計を見直すべきなのでしょうか？

私だったら、それぞれのモデルクラスに集計用のメソッドを書いて、それを内部で呼び出す形式にします。
で、後々パフォーマンス等々の問題が出たときには、それぞれのメソッドでがさっと取ってくるように変更してゆきます。
まあ、中間のメソッドが必要ないのであれば、最上位のuserに一括でemploymentを取得して集計するようにしますが。

class User < ActiveRecord::Base
  has_many :shops
  # 普通に使うとき
  def total_payment
    payment = 0
    self.shops.each {|s| payment += s.total_payment }
    return payment
  end

  # 高速化してみる
  def hi_speed_total_payment
    user_table = User.arel_table
    shop_table = Shop.arel_table
    emp_table = Employment.arel_table
    join_s = emp_table.join(shop_table, Arel::Nodes::OuterJoin).on(emp_table[:shop_id].eq(shop_table[:id]).join(user_table, Arel::Nodes::OuterJoin).on(shop_table[:user_id].eq(user_table[:id]).join_source
    total = 0
    Employment.joins(join_s).where(user_table[:id].eq(self.id).each do |emp|
      total += emp.total_payment
    end
    return total
  end
end

class Shop < ActiveRecord::Base
  belongs_to :user
  has_many :employments

  def total_payment
    payment = 0
    self.employments.each {|emp| payment += emp.total_payment }
    return payment
  end
end

class Employment < ActiveRecord::Base
  belongs_to :shop

  def total_payment
    return self.price * self.hour
  end
end

Railsを使っていて、パフォーマンスの問題が出るのは、ネストの深さというよりは、DBアクセスのオーバーヘッドにボトルネックがあるので、(eachで回してると、それぞれのeachの中でDBアクセスが発生する)パフォーマンスの問題を考えるなら、どこでDBアクセスが発生しうるのかを考えるのがポイントかと。
eager_loadingとか使ってて、あらかじめ関連インスタンスをメモリにロードしてる場合はループで回しても同じとか、その辺を考える分けです。

可読性の問題とか、その辺を考えるなら、モデルクラスのメソッドをコールして、その内部でループを回す方法が良いかと思います。

SQLで条件を定義するのが困難な場合を除いて、集計はDB側でやるのがセオリーです。集計のためにアプリケーション(Rails)側でループを回すのは典型的なアンチパターンです。

モデルの構造がわからないので想像ですが、

User.first.shops.select('SUM(employments.price * employments.hour) AS total').joins(:employments).first.total

こんな感じで行けるんじゃないでしょうか。

他の方がきっとしてくれるであろう回答が勉強になりそうで楽しみです。

私としてはネストの深さより、スクロースせずに見える範囲にループが収まるか否か、という方を重要視する場合が多いと思います。ループが 3 重くらいでも素直な構造のもの (たとえば x, y, z 軸についてのループとか) でループ全体が 20 行で収まっているなら特におかしいとは思いません。実際にはネストの深さというか、条件分岐なども含んだインデントの深さで考えますが。

他のところの処理にもよりますが、今回のようなケースで、クラスを用いてさらにコードのネストを減らすことは有用なことも少なくないと思います。ネストを減らすことが目的ではなく、コードの見通しをよくし、仕様変更などに強くするのが目的になりますが。
具体的には、Shop クラスを作って totalSalary という getter を用意し、Employment クラスを作って salary という getter を用意する、という感じでしょうか。たとえば、支店ごとの合計の他に、支店内の部署ごとの合計も出したい、とかなったときに Employment クラスには手を入れなくても対応できるようになります。