Иннокентий Волнин

В первую очередь статические методы и классы это не комильфо не потому, что не ООП, а потому, что во первых, дают жесткую привязку к коду, код становится негибким, а во вторых, тестировать код, наполненный статикой - проблемно, дают много зависимостей от которых не абстрагироваться. Плюс глобальная видимость.

Статические методы удобно, когда их используешь просто как глобальную функцию, которая нужна во многих местах, например, преобразовать строку или дату к какому-то виду. Только такая функция не должна содержать бизнес логику. В многопоточном режиме может возникнуть проблема в тех же случаях, что и во всех остальных - когда внутри метода изменяются данные с общшим доступом.

Если возникает необходимость сделать статические методы с логикой посерьезней фильтра списка, например, доступ к БД, то есть пара вариантов в этом случае. Первый, сделать синглтон, если хотите, чтобы была одна точка входа для доступа к БД и Вы хотите эту точку и попытки получения данных из БД контролировать.
Второй, это иньекция зависимостей и контейнеры для них, всевозможные IoC. В настройках IoC указываете, что выдавать единственный экземпляр и он по сути сам станет singlton, фабрика контейнера не будет на каждое обращение создавать новый экземпляр.

Лично я статическими методами и даже полями пользуюсь. Иметь хелперы, это удобно, но, конечно, без фанатизма.

Узнал от(значительно) более опытного коллеги, что использование статических методов считается нарушением принципов ООП.

Ну как бы основной принцип ООП построение программного кода на основе объектов. Что такое объект? это некая сущность имеющая состояние и имеющая методы работающие с этим состоянием. Любые статические компоненты - относятся не к объектам а к классу.

Соответственно, я могу сделать метод и сам класс статическим(и иметь красивый код) или не делать(и каждый раз создавать экземпляр класса, чтобы вызвать метод) .

В некоторых случаях такой подход уместен, например при создании классов-хелперов. В остальных случаях нет.

Что будет занимать больше памяти и как вообще в обоих случаях будет работать сборщик мусора?

Какая разница? Это экономия на спичках в которой нет смысла

Что будет работать быстрее?

Все зависит от компилятора

Есть ли у статического варианта какие-то подводные камни, например, при вызове из нескольких потоков?

Статический метод от глобальной функции отличается только тем что он привязан к классу. Делайте выводы...

в C# есть очень элегантный механизм расширений возможностей существующих обьектов, он так и называется - расширения
https://docs.microsoft.com/ru-ru/dotnet/csharp/pro...
https://metanit.com/sharp/tutorial/3.18.php

но реализуется он только статическими методами, и только в статических классах

следующий пример - фабрики классов, так вот в C#, наиболее естественным образом, фабрики реализуются именно статическими методами

всем этим приемам есть свое место и время, просто надо в этом разобраться

ps

Соответственно, я могу сделать метод и сам класс статическим(и иметь красивый код) или не делать(и каждый раз создавать экземпляр класса, чтобы вызвать метод) .

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

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

Есть ли у статического варианта какие-то подводные камни, например, при вызове из нескольких потоков?

у методов может и нет, зависит о того к чему они обращаются? если вызываете другие потокобезопасные методы (библиотечных классов) + изучите и будете применять потокобезопасные алгоритмы - какие могут быть проблемы? (пример - расширения LINQ, который вообще почти полностью на расширениях то и построен (то есть в основном на статических методах))

но помните о остатических полях! - даже если класс не статический, он может иметь статические и методы и поля. статическое поле - так же один единственный экземпляр на всю программу, даже если сам класс не обьявлен статическим. а значит потокобезпасным он может быть, только если статическое поле используется readonly

вывод - статика классная штука!... однако применять ее действительно надо только тогда, когда ясно понимаете что делаете? и зачем делаете именно так?

договориться с корпоративным ресурсом, чтобы он давал доступ к себе только по шифрованному VPN-подключению. настроить это подключение. оборудование зависит от того, на что договоритесь с корпоративным ресурсом, в целом в минимальном варианте достаточно только софта.

Поднимай VPN. Доступ к ресурсу только с адресов 192.168.*.* или 10.10.*.* то есть с локальной сети.
Весь внешний трафик только через VPN туннель.
Весь внутренний трафик по локальной сети, без туннелей.