Inspector に独自のイベントを設置したい

引数なし

引数なしの場合は簡単で、以下の記述だけで出来ます。

public UnityEvent noArgument;

テストコード

<EventTest.cs>
using UnityEngine;
using UnityEngine.Events;

public class EventTest : MonoBehaviour
{
	public UnityEvent noArgument;
	
	public void FireEvent()
	{
		// イベント発生
		// event call
		noArgument?.Invoke();
	}
}

<Caller.cs>
using UnityEngine;

public class Caller : MonoBehaviour
{
	public void NoArgument()
	{
		Debug.Log("no argument.");
	}
}

Inspector のアタッチ例

引数あり

引数ありの場合、記述方法が少し増えます。
UnityEvent<string> の string をお好みの引数に変えてご使用ください。

[Serializable]
public class UniqueEvent : UnityEvent<string> {}
	
public UniqueEvent stringArgument;

テストコード

<Event.cs>
using System;
using UnityEngine;
using UnityEngine.Events;

public class EventTest : MonoBehaviour
{
	[Serializable]
	public class UniqueEvent : UnityEvent<string> {}
	
	public UniqueEvent stringArgument = null;
	
	public void FireEvent()
	{
		// イベント発生
		// event call
		stringArgument?.Invoke("argument");
	}
}

<Caller.cs>
using UnityEngine;

public class Caller : MonoBehaviour
{
	public void StringArgument(string str)
	{
		Debug.Log($"string: {str}.");
	}
}

テストコードのように、呼び出し側で引数を変えたい場合、Dynamic string の中にあるメソッドをセットしなければいけない事に注意してください。
Static Parameters の場合、Inspector で固定値を設定することしかできません。

Inspector のアタッチ例(Dynamic を選んでいる)

インスペクタ (Inspector) でイベント設定することのメリット、デメリット

メリットはやはり、GUI から入るであろう初級～中級者でも理解しやすいところでしょうか。
デザイナーに設定をまかせる場合は、断然インスペクタが好まれると思います。
インスペクタからイベント構造が見える（何をやってるか把握しやすい）のも利点です。

１番大きなデメリットは「名前を変える（リファクタ）」と、設定した依存関係が消えてしまうことです。
様々なシーンで大量に使っているオブジェクトだとほぼ死亡確定と言えるので、名称は最初のうちに、なるべく適切な名前にしてください（間違っても foo とかやらない）。
オブジェクトやアセットはGUIDがあるので、名前を変えても依存関係は消えないんですけどね…。
構造上仕方ないとはいえ、ちょっと残念です。

基本的にプログラマ寄りだと不要、デザイナよりだと必要と考えがちですが、私は「チームとして浸透しやすく、かつミスを担保しやすいのはどちらか」で考えるといいと思います。
インスペクタで設定できるけど、実行時にソースコードが勝手に変更する…といったごちゃごちゃコーディングスタイルは避けましょう。