ご質問ありがとうございます！
僕もLooker導入前は、何度説明を聞いても具体的なイメージがつきませんでしたので、お気持ちわかる気がします。

誤解を恐れずに言うと、LookMLでできるのはSQLのモジュール化です。

実際に使ってみるとわかるのですが、
LookMLでは、SQLをLookerのルールに従ってバラバラにして、
役割分担してまとめ直すようなことを行います。
そして実際にアウトプットされるのは、SQL文です。

SQLと関係ないオプション的な情報もLookerMLで付与できますが、
最も重要なLookMLの機能は、Lookerの世界観に従ってSQLを管理・発行することです。

一応「LookMLとは？」の公式ドキュメントも貼らせて頂きますね。
https://docs.looker.com/ja/data-modeling/learning-lookml/what-is-lookml

すみません、この説明でも昔の自分にわかってもらえない気がしておりますが、以上お答えさせて頂きます。

ご質問ありがとうございます！

弊社内でも、Lookerを契約したのが今年1月かつモデリング層を操作しているのが私1人ということもあり、まだ実際に困難を感じたり、解決策を取っているわけではないのですが、今後を想定してお答えさせて頂きます。

まず、

長期的に使っていた時、モデリング層の設計思想が属人化しやすい気配を感じました

につきましては、その通りだと思います。

そのため、組織内でポリシーを定めることがその対策になってくるかと思います。
ポリシーを定めるとして、一口にモデリング層と言っても対応可能領域が広いので、
より基礎となるデータに関する部分ほど厳密にして、
アウトプット形式に関するような部分は割と緩くするかなと思います。

そしてそれだけポリシーを定めたり、ガバナンスを効かせるとなると、
Looker専任に近いエンジニアの方はどうしても必要になってくるかな〜と思っております。

それから申し遅れましたが、DeNAさんがこちらの問題への対処について、過去発表されておりましたので、ご参考頂けたらなと思います。むしろこちらが答えとして完璧そうです 笑。
https://speakerdeck.com/dena_tech/detahafen-san-guan-li-he-looker-wohuo-yong-sita-ci-shi-dai-detapaipurain

追伸
将来Looker使うことになった暁には、ぜひ意見交換して参りましょう！

ご質問ありがとうございます！こちら弊社では

＜社外用ダッシュボード提供＞
・1周目：Looker導入のためのPoC期間で、経営会議でデモするためのダッシュボードづくり
・2周目：クライアント提案用のテストダッシュボード作成
・3周目：クライアント販売・提供用のダッシュボード作成

というフェーズがありまして、それぞれ再構築する前提で、読み込むデータマートのワークフロー部分も含めてゆるく作って進めていきました。また並行して、社内用にダッシュボードを整備しながら経験値を積むこともできました。（なので思い返すと、周回しやすい恵まれた状況ですね 笑）

社内向けの提供のみの場合でも、1回つくってみると、「ああ、あそこはこうすればよかった」という部分が出てくると思います。
また、利用者に触ってもらうと色々出てくるので、それを踏まえて、2、3回、作り直してみるといいかなと思っています。（もしそういう部分が出てこなかったら、それは問題なしということでいいかと思います！）
そして、いきなり全部署向けだと、上のことが実施しにくいと思いますので、まずは特定の部署向けに始めていくといいのかな〜と。

すみません、こちらでお答えになっているかちょっと心許ないですが、以上よろしくお願いします。

ご質問ありがとうございます！

そうですね、API連携や、容易に埋め込めるのもLookerの特徴として有名ですが、それ以外の面白機能として、以下紹介させて頂きます。

Action Hub：所定のサービスに簡単にデータ送信できる機能
https://docs.looker.com/ja/admin-options/platform/actions

マーケットプレイスで提供されているApplications：Google AnalyticsのエクスポートデータやFacebook広告などの共通データを一発でダッシュボード化してくれる機能
https://ja.looker.com/product/applications

Lookerは異なるデータ元でもviewファイルで所定の形式で定義し直せば、等しく可視化可能なので、そういったイケてるダッシュボードを簡単に作れるようになる機能の開発も今後盛んになってくるんじゃないかと期待しています。

ご質問ありがとうございます！

弊社内では、私以外にアドホックにBigQueryを叩いて分析しているメンバーがおらず、何もしていないというのが直接のご回答になりますが、もし仮にそういう状況が発生したとして、お答えさせて頂きます。

この場合、Lookerでカバーしていないデータを扱う高度なデータ分析を行う状況かと思います。
なので、相応のデータ関連スキルを有しているプロフェッショナルなメンバーが対象になるという前提で…。
　1. データには自由に触ってもらうが、ガバナンスはしない
　2. モデリング層の定義ファイルを参照してもらう（公式の定義を提供する）
　3. 主要なダッシュボードを教える（正解となる大元のデータの数字を提供する）
　4. 結果への責任は持ってもらう
という形を取るかと思います。

Lookerだと、2の部分でモデリング層のviewファイルを共通言語として扱うことができるのと、
出力時に生成されたSQL文を見ることができるので、定義を揃える上で少し便利かなと思います。
自由には責任が伴います。「色々したいBigQueryユーザー」には、それだけの覚悟を求めてもいいんじゃないかと考えています。

ご質問ありがとうございます１

はい、データマート（読み込むテーブル）のスキーマに相当する概念として、モデリング層ではdimensionという概念が各viewファイルごとにあります。
https://docs.looker.com/ja/reference/field-reference/dimension-type-reference

そこで読み込むテーブルのスキーマ変更には対応できます。最初にSELECTする時に任意のSQL関数で常に共通の処理をかけるようなイメージです。その方策で、ご質問のケースに対応しきれるかどうかはちょっと判断しきれませんが、一旦以上にてお答えさせて頂きます。

ご質問ありがとうございます１
いくつかの観点でお答えさせてください。

1周目で最も失敗したという意味では、Lookerに集計を寄せすぎて、計算時間の長大化および冗長箇所が発生したことです。これは仕掛けではありませんが、2周目に最も変えたポイントとなります。

モデリングの柔軟性を高めて、より効率的な設計をできるようになったという意味では、Liquidパラメータです。
https://docs.looker.com/ja/data-modeling/learning-lookml/templated-filters

また、これは弊社ゆえのおいしさかと思いますが、スキャンデータ量を減らせたという意味では、ユーザー属性で、BigQueryのクラスタ化したフィールドで制限をかける機能です。
https://note.com/abe_masatoshi/n/n788c40ec62f3#MyGme

なお、こちらにLooker導入時の私のQ&Aをまとめましたのでよろしければご参考ください。
https://note.com/abe_masatoshi/n/n38d9fbae57e8

ご質問ありがとうございます１

はい、どこからLookerのモデリングを始めて、どういう設計にするべきかというのは、利用者の状況に応じて変わるため、実際に試行錯誤するのが近道と考えています。

私も導入前に、Lookerの中の方々やユーザー会で同じような質問をしたことがあるのですが、上記のような回答を頂きました。そして自身も導入してみて、やはりその回答にたどり着きました。

ただ、質疑応答でゆずたそさんが仰ったように、データモデリングに明るい方と一緒に取り組めたら、最適解を得やすくなるのかなと思います…！

あるいは今後Lookerがよりメジャーとなって、たくさんの事例が集まると、ある程度パターンに応じたベストプラクティスが出てくるかもしれません。