つまり、「複数のクラスなんかを使ったら変更が面倒…」っていう意味ですかね? 本題は。
そういう意味であれば「問題はない」と思います。というかもし質問者さんが危惧しておられることが前提となっていたらC#でいう System.Conole.Writeメソッド, C言語でいうprintf関数ですら使えないはずです。そういうメソッドや関数は言語が提供しているというより、ライブラリとして提供されています。
単に「○○ライブラリが~」とかを意識しているのかしていないのかの違いだけです。
よって、本題通りであれば「何も実装できない」ことになってしまいます。
だって、二つのメソッド(C言語だと関数)を作ってmethod1がmethod2を呼び出す…みたいな実装になっているだけでも、「もしこのmethod2の内部処理が変更されて、"ファイルから一行読み込む"だったのが"バイナリファイルに記述されているデータの一部を取り出す"とかになったとかで戻り値まで変更になった」とかもあり得ますよね。(さすがにこの例はあり得ないけど、これレベルの変更があっても不思議ではない)
(本題の意味で)結合度を低くしようとするとやっぱりmethod2もmethod1も作れないし、作れたとしてもmethod1にべた書きになる。というかC#の場合はMainメソッドがすでにあるから別のメソッドを作っただけで結合度が…
一般的に言われている「結合度が低」(今回は「疎」と言っている)は「クラスの構造が変更されても呼び出し側には影響がない」のと「メソッドの引数や戻り値、メソッドの基本的な内容が分かっていればいい」ですね。
たとえばここを参考にすると、
(スタンプ結合)
userIdだけあれば事足りそうですが、Userインスタンスを渡してしまっています。別に問題ないように見えますがUserインスタンスのデータ構造に依存してしまっているのが問題です。
(データ結合)
参照するモジュールで使うデータだけを、個々の引数で受け渡ししている状態を指します。引数が多くなるとモジュールを参照するために、自分が必要じゃないデータを渡す必要があったりします。
とあります。スタンプ結合、結合度は下(低)から数えて二番目ぐらいでしょうか、この結合ではクラスのデータ構造(どういうプロパティを持っているかとか)を知らないといけないし、不要なデータも含んでいます。
データ結合(一番下)はそのメソッドが使うデータだけを渡していますから、データ構造を知らなくても必要なものだけ知っていればいいのです。引数として渡すデータを構造体とかにしてそれを受け渡すとかの場合は必要なものだけなら結合度は低のようですね。
つまり、「クラスの(内部の)データ構造とかが変更される場合」や「メソッドの処理内容等が変更される場合」に呼び出し側にまで修正が及ぶかどうかだと思います。
Unityとかで提供されているクラス等が変更される可能性は無いとは言いませんが、それを言い出したらそもそもC言語とかで使えるprintf関数みたいな言語レベルでサポートされていると思われているクラス等ですら使えませんよ。
こういったライブラリの導入自体なるべくやめた方が良いのでしょうか。
今回の意味でいえば『問題ない』です。ただし、ライセンス的に不可能だったり、チーム開発とかでの取り決めとかで見送るとかはありそうですね。