Ersteinmal: Warum willst du auf den Boolean zugreifen und was willst du dann machen?
Wenn du das nicht schreibst, können keine alternativen Lösungsmöglichkeiten genannt werden.
Mir sind keine nennenswerten Nachteile bei Events bekannt, allerdings sollte es ohnehin nicht ins Gewicht fallen, wenn das Event alle paar Sekunden, Minuten oder nur "einmalig" ausgelöst wird.
Um nicht direkt auf die andere Klasse zuzugreifen, könntest du entweder eine Basisklasse von dieser Verwenden (diese muss ggf. angelegt werden) oder du speicherst nur eine Referenz auf das GameObject und arbeitest dann mit SendMessage (fast das gleiche wie ein Event, nur mit geringeren Abhängigkeiten). Für letzteres wäre ganz nützlich zu wissen, dass die Methode auch einen optionalen Parameter vom Typ SendMessageOptions entgegen nimmt.
Wenn du nicht gerade ein Framework schreibst, welches gänzlich unabhängig von irgendwelchen anderen Klassen sein muss (die ja dann ggf. von anderen später geschrieben werden könnten), dann sehe ich kein so großes Problem darin, bestimmte Abhängigkeiten in Kauf zu nehmen. Allerdings sollte man immer überlegen, ob man wirklich ein Objekt dieser konkreten Ausprägung (Klasse) braucht oder ob es später nicht noch andere geben wird. Wenn letzteres der Fall ist, sollte man sich über eine geeignete Basisklasse oder eine Schnittstelle Gedanken machen.
Ein Beispiel, um die verschiedenen herangehensweisen zu veranschaulichen:
In dem zu entwickelnden Spiel gibt es Pickups (Items, die aufgehoben werden können und eine bestimmte Aktion ausführen).
Möglichkeit 1: Jedes Skript handhabt alles (Aufheben des Pickups, Auswirkung, Zerstörung (da verwendet), ggf. Zerstören des Pickups durch andere Fremdeinwirkungen)
Möglichkeit 2: Ein Skript handhabt das Aufheben und das Zerstören und ein anderes die Wirkung, Kommunikation über SendMessage
Möglichkeit 3: Ein Skript handhabt das Aufheben und das Zerstören und ein anderes, welches von einem Interface/einer Basisklasse abgeleitet ist, handhabt die Wirkung, Kommunikation über direkten Aufruf des entsprechenden Methode
Möglichkeit 4: Ein Skript stellt die Basisklasse dar und handhabt das Aufheben und Zerstören, das zugewiesene Skript erweitert dieses Skript um die Wirkung
Möglichkeit 5: Ein Skript handhabt das Aufheben und das Zerstören und entscheidet anhand eines Enumerationswert, was die Auswirkung ist (Kombinierbar mit Erweiterungsmethoden)
Möglichkeit 6: Ein Skript handhabt die Auswirkung und sucht zu Beginn nach dem anderen Skript, welches für das Aufheben und Zerstören zuständig ist, um sich dort bei einem Event zu registrieren
...
Auf Anhieb klingt vielleicht die eine Möglichkeit besser als die andere, allerdings gibt es noch Aspekte, die den Sinn diverser Möglichkeiten beeinflussen:
Es kann beliebig viele Wirkungen geben (die jeweils eigenen Code erfordern). -> Grundsätzlich mit allem Machbar, bei einer Enumeration muss diese jedes Mal erweitert werden, bei Möglichkeit 1 und 4 entsteht für jede Variation ein Skript.
Es kann beliebig viele Arten des Aufhebens/Zerstörens geben (verbrennen, zerquetschen, ins Wasser fallen/ertrinken, durch Sturzschaden, Aktivierung bedingt durch andere Items/Fähigkeiten...). -> Für das am Event Registrieren ist eine Basisklasse/ein Interface erforderlich, bei Möglichkeit 1 entsteht für jede Variation ein Skript.
Es können mehrere Wirkungen einem Gegenstand zugewiesen sein. -> Bei Möglichkeit 3 und 5 könnte es passieren, dass Anpassungen hierfür notwendig sind (Suchen/Zuweisen mehrerer Wirkungen, nicht nur einer), bei Möglichkeit 1 und 4 entsteht für jede Variation ein Skript.
Diverse Items Besitzen mehrere Aktivierungsmöglichkeiten -> bei Möglichkeit 1 und 4 entsteht für jede Variation ein Skript.
...
Abgesehen davon gibt es diverse Aspekte, die vom jeweiligen Geschmack abhängig sind:
Soll es je Item nur 1 Skript geben, welches es zum Item macht?
Muss für eine andere Wirkung ein anderes Skript angehanden oder ein Wert aus einer Liste ausgesucht werden?
In anderen Fällen würden sich nicht nur andere Möglichkeiten eher anbieten, sondern evtl. auch noch ganz andere Möglichkeiten überhaupt erst in den Sinn kommen.