What's important to understand is that the .NET MicroFramework is a memory-managed run-time environment. To simplify the explanation, it is basically a program that implements a virtual machine. The benefit of this is that the code that you write at the application level runs on this virtual machine and gets to use all kinds of dynamic objects that can grow and shrink in size and disappear when you don't use them anymore - and all this happens nicely behind the scenes.
This diagram represents all the components required to make this happen. The C# code that you write is at the application level and is "Managed" which runs in the "virtual machine". Everything below that is "Native" - which runs on the actual hardware. At some point someone had to port the framework onto a particular piece of hardware for you - this is done at the HAL (Hardware abstraction layer) which they had to write.
So as you can see, all these components can add up to a very large code size (Flash), a lot of RAM at run-time, and a lot more CPU cycles than it would take to run a natively compiled C program.
This is why .NET MF devices require a lot of resources and why an ARM7 is actually not overkill if you want decent performance and enough room for your C# application.
Here is a netduino forum post talking a bit more about this.
To answer your question of what might be the cheapest way to get a .NET MF board with ethernet, it would probably be to copy the netduino+ design, except with only the components you need and to use their .NET MF port - which they've put a lot of effort in to but have made accessible from what I understand.