I'm gathering that it's nearly a waste of time to try to reverse .NET applications in a native debugger. But why? Of course the computer is executing machine code in the end, not CIL. So what clutters the x86-64 code so much when running a .NET application? Is the general rule to use native debuggers on native code and tools like ILSpy on .NET?
Microsoft .Net uses CIL (Common Intermediate Language). It is a - bytecode - assembly language for a virtual machine which is an abstract stack-based CPU - by abstract I mean not implemented in hardware.
Therefore, x86 gdb cannot make sense of the .Net bytecode given that all it knows is x86 assembly. But, in general you can easily reverse a bytecode into source code (because the VM states are more deterministic than those of a hardware CPU) or debug it using and .Net virtual machine with debug capabilities (i.e. ILSpy). If you want more info on debuggers/decompilers/... for .Net check out this link. Also, if you debug with gdb, you're most likely to be debugging the VM assembly code rather than the .Net bytecode of the application. In other words, what you are seeing is the VM running bytecode, not the bytecode running.
I think it's more that you're debugging the code that launches the runtime assembly (and produces an error if it's not found) then after that is just pure MSIL which is effectively in another language (rather than machine code), which gets interpreted by the runtime (think of it like Java bytecode).. which will be meaningless without translating that to what the virtual machine would do... which a good .NET decompiler would actually convert to code for you anyway.