OK, just to poke some holes in that rant you linked:
- "C# relies on a "Just In Time" interpreter" - wrong - it is a JIT compiler. After a method is JITted once, the compiled code is reused for each invocation. The compiled code is very close to as fast as native, pre-compiled code.
- "Xenon CPU is an "in place" processor" - does he mean "in order"? - And: "Xenon CPU has no branch prediction". He implies these mean that JIT compiling naturally produces bad code that must be re-ordered by the CPU and causes lots of branching - which is absolute nonsense. The same performance advice for running on this CPU architecture applies to both C++ and C#.
- "[JIT] requires constant flushing on the 360" - wrong, the compiled code can be kept in cache like any normally compiled code. (If he means pipeline flush, see the above point.)
- "generics [...] use code generation" - generics are JITted like everything else and, like everything else, the JITted code is fast. There is no performance penalty for using generics.
- "all the sexy bits of language [...] require either branch prediction..." - how does this not apply to C++ as well? - "...or [...] in-place code generation" - does he mean JITting? Did I mention that it's fast? (I won't go into all the places the desktop CLR uses actual code generation - a feature not supported by the Xbox 360!)
- "[C# doesn't have] the massive libraries [of C++]" - except, say, XNA itself? And plenty more. (Still, this is a somewhat fair point.)
XNA on the Xbox 360 runs on a modified version of the .NET Compact Framework CLR. I have no doubt that it's not up to the standard of the desktop version. The JITter probably isn't as good - but I don't think it's bad either. I'm surprised he didn't mention the garbage collector which is dreadful compared to the desktop CLR.
(Of course - you shouldn't be hitting the garbage collector in a professionally developed game anyway, just as you must be careful with allocations in any professional-grade game.)
(For actual technical discussion of the .NET Compact Framework, perhaps start with this article series: Overview, JIT Compiler, and GC and heap.)
The way he is entirely unspecific about his terminology makes it difficult to even understand what he means. Either he's in maximum-rant mode, or doesn't know what he's talking about.
Now that we've got that out of the way, here are some things that you do miss out on by using XNA on the 360, rather than going native:
- Access to the SIMD/Vector unit for doing really, really fast CPU floating point maths
- Ability to use native language code that will probably be a little bit faster than C#
- Ability to be a little bit lazier with how you allocate memory
- XBLIG games have access to only 4 of the 6 cores (but we still get all 3 CPUs, and they're not full cores either, so we don't miss out on much) - not sure if this applies to non-XBLIG XNA games
- Full DirectX access for doing really obscure graphical trickery
It's also worth pointing out that these are only CPU-side restrictions. You've still got completely free access running on the GPU.
I described these things in this answer to what is effectively the same question as this one. As I mentioned in that answer XNA is absolutely suitable for "professional" development.
The only reasons you'd avoid is is because you can't hire C# talent, licence C# engines, and reuse existing C# code the same way you can with the existing base of C++ knowledge. Or because you might also be targeting a platform that does not support C#.
Of course, for many of us who aren't "professional" developers, XNA is our only option to get on the Xbox 360, making the point moot.
To answer your other questions:
Nothing in C# stops you using data-oriented approaches in essentially exactly the same way you'd use them in C++.
C# lacks the ability to automatically inline code at compile-time, and (without going off to check) I'm pretty sure the compact CLR's JITter can't inline methods (the desktop CLR can). So for performance-critical code you may have to manually inline in C#, where C++ provides some assistance.
Probably a bigger reason why you don't often see CPU-maths intensive things like collision detection and fluid simulations in C# is lack of access to the vector unit (as mentioned above).