Hello folks ...
Well who ever spoke of performance is absolutely right ...
The "classic" switch will do the job much more efficiently than any other implementation version.
I like the elegacy of the code above also but performance wise is nowhere near the simple "switch" statement solution.
I run a benchmark test (using the BenchmarkDotNet v0.13.7 package) for the above (renamed as AmIAfraid02) implementation.
The last one (AmIAfraid03) is the one using the "switch" statement.

See the summary for yourselves:

// * Summary *

BenchmarkDotNet v0.13.7, Windows 10 (10.0.19044.3086/21H2/November2021Update)
Intel Core i5-7500 CPU 3.40GHz (Kaby Lake), 1 CPU, 4 logical and 4 physical cores
.NET SDK 7.0.400
[Host] : .NET 6.0.21 (6.0.2123.36311), X64 RyuJIT AVX2
.NET 7.0 : .NET 7.0.10 (7.0.1023.36312), X64 RyuJIT AVX2

Job=.NET 7.0 Runtime=.NET 7.0

// * Hints *
Outliers
BenchmarkAmIAfraidMethod.AmIAfraid02: .NET 7.0 -> 4 outliers were removed (218.49 ns..220.67 ns)
// * Config Issues *

// * Warnings *
Configuration
Summary -> The exporter BenchmarkDotNet.Exporters.MarkdownExporter is already present in configuration. There may be unexpected results.
Summary -> The exporter BenchmarkDotNet.Exporters.HtmlExporter is already present in configuration. There may be unexpected results.
Summary -> The exporter BenchmarkDotNet.Exporters.Csv.CsvExporter is already present in configuration. There may be unexpected results.

// * Legends *
Mean : Arithmetic mean of all measurements
Error : Half of 99.9% confidence interval
StdDev : Standard deviation of all measurements
Ratio : Mean of the ratio distribution ([Current]/[Baseline])
RatioSD : Standard deviation of the ratio distribution ([Current]/[Baseline])
1 ns : 1 Nanosecond (0.000000001 sec)

// ***** BenchmarkRunner: End *****
Run time: 00:00:59 (59.8 sec), executed benchmarks: 3

Global total time: 00:01:05 (65.47 sec), executed benchmarks: 3
// * Artifacts cleanup *
Artifacts cleanup is finished

It's still a linear solution. It does create extra strings, but the difference shouldn't be significant, just a constant factor.

I am replying to my self, here as the kata definition clearly states that "the inputs are never null".
I added some null checking to my solution anyway so I guess yours is indeed the optimal
as well as the most elegant one. Maybe a readonly modifier should be added to the private fields definitions.

Hello folks !
I really like the elegance of the expression body definition as well as string interpolation,
but the call to the Trim() function will return an null reference exception in the case of a null string input ...
Won't it ?