Что (не)нужно знать для создания игр на Unity

Проблема вторая — КОММУНИКАЦИЯ

Есть паттерн пул, сделать событие на окончание звука и передачу AudioSource в пул — дело 3-5 строк кода. А в пуле держать только N играющих источников, с контролем их количества — дело одной строки.

скрипт не знает напрямую на каком объекте в данный момент выполняется

Как не знает?

this.gameObject

как раз и показывает кому он принадлежит (там ещё и трансформ есть)

Объект отвечает за отображение игрового счета и за воспроизведение всего игрового звука, так на мой взгляд экономичнее для памяти

Нарушение принципа «одна сущность — одна задача», экономия памяти незначительна

его можно нагрузить (о, ужас) использованием PlayerPrefs (читай — записью в файл)

Он кешируется в любом случае, а запись «в файл» (хотя в Win системе он пишет в реестр) делается принудительно через PlayerPrefs.Save
Но раз есть класс настроек, то достаточно сделать методы Load и Save, в которых и будет чтение/запись, а данные брать из полей (после загрузки).

Проблема пятая — ОДНА ДЛЯ ВСЕХ

Тут лучше применить паттерн Singleton

using UnityEngine;
public class DontDestroyThis: MonoBehaviour {
  public static DontDestroyThis Instance { get; private set; }
    void Awake() {
      if (Instance != null) {
        Destroy(this);
        return;
      }
      Instance = this;
      DontDestroyOnLoad(this.gameObject);
    }
}

Так и доступ есть, и контроль только одного инстанса на сцене, и возможность использования этого объекта в каждой сцене при запуске из редактора.