I think a lot of it has to do with the marketing aroud XNA. The audience they are targeting is the hobbyist and independent developer, and most of the games produced by such an audience are small-scale. As for performance, I think the number I heard a while ago for XNA was like 98% of native.

The only ones I can think of right off the bat:
-Portability, constrained to PC/360/Zune
-Controller support is limited(I heard it only supports the 360 controller)

I have yet to use XNA yet, so I'm sure someone can add more, or correct me if I'm wrong.

Well when you're specifically talking about the 360, the main disadvantage compared to having a real dev-kit is that you don't have full low-level access to machine's capabilities, and instead have to go through a managed API. This brings the following problems:

-You can't manually manage memory. On the PC this is hardly a big deal at all (since even in native code you're working with virtual memory anyway), but on the 360 it's a different story. You have a very very limited set of memory to work from, and if you're looking to make full-scale commercial-level games you will probably come up against the limits pretty quickly. For smaller games it shouldn't be a problem.

-You have to work with .NET CF's garbage collector. Whether you love working with one or not on PC, on the 360 the situation is once again different because GC compactions can cause some serious latency. You have to be careful and forward-thinking with how you handle your data to avoid this (for example, using structs and making sure they don't get auto-boxed).

-No access to Xenon's (360 CPU) vector unit. Because of this your floating-point abilities are limited compared to many PC CPU's, or what commercial devs can achieve.

-No native access to Xenos (360 GPU). You're essentially limited to what you can pull off in D3D9, so that XNA is consistent for both the PC and the 360. This means you can't work with native command buffers, read from the GPU's z-buffer, manually manage tiling, or use MEMEXPORT. Also the biggest problem, IMO, is that you can't use the special FP10 back-buffer format. This is a special 32-bpp format that allows you to use floating-point components while still maintaining a small footprint for your back-buffer (which is important since a larger back-buffer means more tiles are needed in order to fit in the 10MB of eDRAM). Without this you have to either use A16R16G16B16F (which has twice the footprint and doesn't support HW blending) or some custom color-space in A8R8G8B8 (requires special shader math which adds complexity, also can't be alpha-blended).

-You can't sell your game, unless you find a publisher or somehow get MS to publish it for you.

The other serious limitation is that the XNA Framework on Xbox 360 restricts your application space to 2.0 GB in size - this includes source code and game assets.

While most games by small or independent developers will never approach the 2 GB cap, contemporary commercial games are now reaching 10+ GB of game data. As an extreme example, Age of Conan just released with a record breaking 24 GB install after patching. That's a factor of 10 over what's allowed by the XNA Framework for Xbox 360 games.

Cheers!