This is likely a deoptimization. Decomposing DateTime has its overhead.

This method is never called in practice. And hopefully there will be no more leap seconds added in the future.

This is not a good practice. The static method doesn't save anything.

The calling convention for struct instance methods always forces the struct on stack, unless the method is inlined.

I see the problem in calling convention. Is there any measurement about the performance impact?

It's anti-pattern to operate on raw bits rather than reusable properties.

This is the reusable property (InternalKind is inefficient for this purpose).

InternalKind is expected to be efficient. What's the problem here? It should always be inlined.

Using shift instead of mask produces smaller code (due to the large values of FlagsMask, etc.).
I measured 3 different common scenarios using 3 different approaches:

int _ops = 1000;
DateTime _empty;
DateTime _utcNow = DateTime.UtcNow;

[Benchmark(OperationsPerInvoke = 1000)]
public int DateTime_Kind()
{
    int res = 0;
    int c = _ops;
    DateTime value = _empty, next = _utcNow;
    do
    {
        res += (int)value.Kind;
        value = next;
    } while (--c > 0);
    return res;
}

[Benchmark(OperationsPerInvoke = 1000)]
public int DateTime_KindBranch()
{
    int res = 0;
    int c = _ops;
    DateTime value = _empty, next = _utcNow;
    do
    {
        if (value.Kind == DateTimeKind.Utc) res++;
        value = next;
    } while (--c > 0);
    return res;
}

[Benchmark(OperationsPerInvoke = 1000)]
public int DateTime_KindSwitch()
{
    int res = 0;
    int c = _ops;
    DateTime value = _empty, next = _utcNow;
    do
    {
        switch (value.Kind)
        {
            case DateTimeKind.Unspecified: res += 7; break;
            case DateTimeKind.Utc: res += 9; break;
            default: res += 3; break;
        }
        value = next;
    } while (--c > 0);
    return res;
}

readonly statics are JIT-time constants, removing this doesn't improve any performance.

class C
{
    static readonly long s_minDateTicks = DateTime.MinValue.Ticks;
    static readonly long s_maxDateTicks = DateTime.MaxValue.Ticks;
    [MethodImpl(MethodImplOptions.NoInlining)]
    static long GetMinTicks() => s_minDateTicks;
    [MethodImpl(MethodImplOptions.NoInlining)]
    static long GetMaxTicks() => s_maxDateTicks;
}

Tier-1 codegen for GetMinTicks and GetMaxTicks:

; Assembly listing for method C:GetMinTicks():long (Tier1)
G_M18344_IG01:  ;; offset=0x0000
						;; size=0 bbWeight=1 PerfScore 0.00
G_M18344_IG02:  ;; offset=0x0000
       xor      eax, eax
						;; size=2 bbWeight=1 PerfScore 0.25
G_M18344_IG03:  ;; offset=0x0002
       ret      
						;; size=1 bbWeight=1 PerfScore 1.00

; Assembly listing for method C:GetMaxTicks():long (Tier1)
G_M12726_IG01:  ;; offset=0x0000
						;; size=0 bbWeight=1 PerfScore 0.00
G_M12726_IG02:  ;; offset=0x0000
       mov      rax, 0x2BCA2875F4373FFF
						;; size=10 bbWeight=1 PerfScore 0.25
G_M12726_IG03:  ;; offset=0x000A
       ret      
						;; size=1 bbWeight=1 PerfScore 1.00

They are not guaranteed to be JIT time constants and only work well with tiered compilation. New code should try to avoid such fields for constant values.
Previous discussion: #58169 (comment)

For runtime doesn't run tiered compilation like NativeAOT, static readonly fields like the above are always preinitialized so this won't be a problem.

static readonly fields like the above are always preinitialized so this won't be a problem.

That's not correct in this case today. DateTime.MaxValue.Ticks is too complicated expression for NAOT compiler to interpret at build time: https://godbolt.org/z/bdcErcEa6

If there's an improvement to be gained from the intermediate cast, shouldn't the JIT be able to just generate better code accordingly, given it knows from L290 that kind is in range of a uint?
cc: @EgorBo

@stephentoub unfortunately, it's not yet handled by JIT for shifts (just checked), but it should be trivial to implement. Minimal repro. I'll take a look.

It's not the shift but extension to ulong before shifting: repro should look like that.

What is the benefit of this manual outlining? Does the ctor get inlined automatically with this factored out but not with it left in line?

The ctors are quite inlineable in both cases, but this just reduces the code size footprint of leap seconds even further: https://www.diffchecker.com/TbFmWwyz/

Same question

The ctors that don't use Calendar now take advantage of the fact that year/month/day (+kind) can be converted to ticks before leap seconds check, thus reducing the number of ctor variants that need to directly handle leap seconds and saving on code size: https://www.diffchecker.com/Iuqa8iGs/

This appears to be optimizing for the case where provider is null at the expense of more code at the call site... why is that desirable?

I took this approach from NumberFormatInfo which looks like it has been more thoroughly optimized. It adds a small code size increase on some callsites (but not all - in case of const provider = null it's an improvement).