You may be able to convince your coworker with technical reasons that the compiler can inline for them, so this source-level "optimization" isn't helpful.
Hopefully you're exaggerating what they said about it being the whole 3000 line method most optimized possible, or else your coworker is probably clueless about performance optimization and just latching on to something they read once. People who think they know something but don't really understand are sometimes the hardest to convince. I've had several exchanges in stack-overflow comments with people refusing to believe they were wrong, but unable to give a coherent technical explanation that made any sense.
As an asm optimization expert (SO gold badges in [x86], [assembly], [performance], [sse] tags, etc.), I can tell you it's nearly impossible that this function is "the most optimized possible", even if your coworker spent years profiling and tuning it (on some specific hardware? with some specific OS and compiler version?). A function that big will always have room for small tweaks (or new ideas for big changes) that could make it faster, or smaller (machine-code) at the same speed (maybe more hyperthreading friendly to do the same work in fewer instructions).
I don't think the C# compiler + JIT is so bad that it can't inline method calls for you, especially if they only have one call site. I don't know C# (mostly C and C++), but does it have anything like a
static inline non-member function that the compiler can inline instead of emitting a stand-alone definition for, and will do so even if the function is large-ish? Or anything like GNU C
__attribute__((always_inline))? Your coworker could use these to feel like they're getting the optimization they think is important without making the source a nasty mess.
But more importantly, "being optimized" is only worth a tradeoff in readability when the simple baseline version (that you wrote as a starting point, and to benchmark the optimized version against) is slower than you want. You can't tell if you're actually optimizing anything if you don't have a starting point to compare against, and thus judge any readability or machine-code size / instruction-cache footprint tradeoff vs. the speedup.
Writing a less-readable "optimized" version without a simple baseline is usually a mistake, unless you already think you know from experience how the simple version would compile and that it wouldn't be efficient enough. Usually you'd have a simple version as part of a unit-test for a manually unrolled / vectorized version. (This manual-inlining case is maybe different, though. It doesn't make any individual piece of logic more complex or "strangely" implemented. Or does it? Is there manual optimization between blocks?)
Inlining is very often worth it for small functions, but calling a big block of code from multiple call sites only uses the instruction-cache footprint once. It does pay the function-call overhead every time, though, so microbenchmarking just the one function, without the full context of the program, can make excessive inlining and unrolling look good. Usually we're fine leaving the decision to modern compiler heuristics; they're usually pretty well tuned, especially if they can do profile-guided optimization to find loops that are actually hot. (JIT compilers operate at runtime, so they do have profiling data if they care to use it. Usually from making a not-fully optimized version or interpreting at first, then using profiling data to speculatively inline virtual methods and stuff like that.)
Sometimes optimization doesn't hurt readability, but in this case it clearly does.
In C++, I often write little
static inline helper functions that will inline into a larger function I'm optimizing the crap out of with SIMD intrinsics. When I look at the compiler-generated asm, there's exactly zero downside in machine-code efficiency, and a nice upside in readability of the source. No stand-alone definition appears anywhere in the executable for these helper functions, so they're not even bloating the executable.
If you want to press the issue, ask your coworker if they've looked at the JIT-compiler's asm output for their method and profiled it, and found those big conditional blocks allowed the compiler to optimize in a way it couldn't with inlining.
Being aware of what your compiler + hardware can do efficiently is not always a bad thing, if you let that inform your coding choices when it doesn't hurt readability.
It's tempting to get sucked into optimizing something that doesn't need to be optimized. Especially if you're only thinking of optimizing for speed of this one function if it was called in a hot loop, when it's not going to be in a hot loop. If it's called infrequently, code cache might be cold, so compact is better. (Fewer cache lines of code to load from main memory.)
This kind of argument only helps if you could factor out any common helper functions from this 3000 line method. Putting each block into a separate function won't make the machine-code smaller. It might make the decision logic for which function to dispatch to more localized, resulting in a smaller I-cache footprint for that, though. And maybe fewer 4k pages touched / loaded from disk / i-TLB