Попытались предоставить возможность безопасно хранить строки
Потом поняли что получилось так себе

А безопасно — это как?

Чтобы строка явно не хранилась в оперативке

RtlEncryptMemory and RtlDecryptMemory

https://docs.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtlencryptmemory там внутри

слушай, а ведь это неплохая идея? как минимум, такая реализация усложнит атакующим жизнь, как, например, это делает обфускация — почему такой подход решили депрекейтнуть?

У меня ощущение, что микрософт не советует использовать это потому что она создаёт ложное ощущение безопасности. Хотя это все ещё немного лучше чем просто стринг
Вообще, в доке ссылка на такое описание: https://github.com/dotnet/platform-compat/blob/master/docs/DE0001.md

Разве сейчас нельзя подобное через обычные конфиги реализовать?

Конфиги?

Ээ? Ну допустим у тебя менеджер паролей. Ты по запросу вытаскиваешь пароль и передаешь в буфер обмена. Допустим в ту же наносек пользователь его использовал.
Но он все еще висит в памяти

Don't use SecureString for new code. When porting code to .NET Core, consider that the contents of the array are not encrypted in memory. The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication.

Понятно, они просто не доделали SecureString в .NET Core. И поэтому в security-critical сценариях рекомендуют отказываться от паролей вообще.

Securestring тоже не особо от такого защищает. Просто окно существования строки в plain text меньше.

When data is not needed anymore SecureString clears the memory used, by zeroing it. This means that data in not kept in memory space managed by dotnet, which is good since GarbageCollector doesn’t get to it.

Они чистят буфер

Открою страшную тайну, но большинство менеджеров паролей тоже не особо запаривается.

уже порекомендовали отказаться от thread.abort

и от использования доменов