Guard классы — использовать или нет?

защищает от типовой ошибки, когда к телу if что-то добавили, но в скобки не взяли

… а получение зависимостей через DI и вовсе делает избыточными null-check в конструкторе.

Простите, но я за такое у нас "убиваю"
Потом на любой переменной после "." выскакиевает огромное количество не нужных мне в этот момент методов.
Это раз.
А два — уже 100 раз писали про экстеншены которые проверяют на нулл. Вы глядя на семантику:

myArgument.CheckForNull()

Сразу ожидаете что если myArgument равен нулл, то вы получите NullReferenceException.
Глядя на этот код не понятно что это экстеншен метод. И именно поэтому вы нигде не найдете такого поведения в стандартной библиотеке.

Так что я настоятельно рекомендую так не делать.

struct IEventProvider {
	int i;
};

struct Manager {
	IEventProvider& eventProvider;
	
	Manager(IEventProvider& eventProvider) : eventProvider(eventProvider) {
	}
};

int main()
{
	IEventProvider* eventProvider = nullptr;
	Manager m(*eventProvider);
	std::cout << m.eventProvider.i;
	return 0;
}

Никаких Guard'ов, особенно реализованных в каких либо Shared/Common или в сторонних библиотеках

Может вообще сторонним библиотекам не доверять? Убрать из кода Json.NET, Moq, Dapper… они делают не менее критичную работу, чем проверка на null.

Никто не может гарантировать корректную реализацию таких вот сторожей, их правильною доработку/развитие.

А кто гарантирует корректную реализацию остального кода, который вы пишете?

Плюс, как писали выше, с ростом исключительных ситуаций, такие классы начинают разрастаться вширь перегрузками, в которых не разобраться со временем.

Сложно представить проект, в котором набор простейших проверок на null, длины строки и т.п. может быть ощутимо сложнее остальной части кода вплоть до "не разобраться". А если вы поместили в гвард бизнес-логику, то это уже не Guard, и на вас налагаются такие же обязанности по обслуживанию этой логики, как и по отношению к остальной части бизнесового кода.

Особенно проблемы с зависимостями могут проявиться, если такие классы реализованы в других библиотеках.

В другой ветке справедливо заметили, что решение проблемы топикстартера по выпиливанию/рефакторингу гвардов решается решарпером за минуты.

public void Test(object o)
{
    Guard.ArgumentNotNull(() => o);
}

public static class Guard
{
    public static void ArgumentNotNull<T>(Expression<Func<T>> argExpr)
        where T: class
    {
        if (argExpr == null)
        {
            throw new ArgumentNullException(nameof(argExpr));
        }
        
        var arg = argExpr.Compile()();
        if (arg == null)
        {
            var argName = (argExpr.Body as MemberExpression)?.Member.Name;
            throw new ArgumentNullException(argName);
        }
    }
}

if (double.IsNaN(weight) || double.IsNegativeInfinity(weight))
{
    throw new ArgumentNegativeException(
        nameof(weight), weight, "Значение параметра не является числом или равно минус бесконечности.");
}
if (weight > 100 || weight < 1000)
{
    throw new ArgumentOutOfRangeException(
        nameof(weight), weight, $"Значение параметра выходит за границы диапазона 0..1000.");
}

Guard.ArgumentInRange(nameof(weight), weigth, 0, 1000);