I would agree with the viewpoint that many folks will want to continue using their established products for the project/resource management, defect management and estimation functionality.
I would also agree that there is not sufficient integration or data interchange capability within EA to productively use the external, purpose-specific tools and also EA together for this purpose (I do think the XMI interchange is OK for modelling aspects though).
However, I would put my two cents in for folks (only plural because I assume I'm not the only one) that are compelled by the prospect of having a single tool that is sufficiently capable to pull off multiple jobs, including project/resource management. For me personally, I generally work in two scenarios:
1) On projects of sufficient scale and finanicial investment to justify it, I work with a dedicated Project Manager or PMO who uses MS Project, Primarvera, etc., a QA analyst using their own tools, and I use the modelling and design tools of my choice (mostly EA these days) separately.
2) On projects of small-medium scale and financial investment, I take on the add'l role of PM and handle the administrative and tracking tasks myself.
Over two smaller project in the past six months, I've found that the admittedly stripped-down functionality in question is adequate for me to do a good job. Only adequate, but for these projects that's been enough for me to do my job thoroughly and timely.
I should note for full disclosure, that my current employer does not purchase many enterprise-level tools, such as the Rational, Embarcadaro or AllFusion products, so these aren't available to me anymore. MS Project are Visio are the tools that are officially available to me. While these are borderline usable tools, they aren't very comprehensive and can only pull off one or two narrow sets of tasks. I was unwilling to attempt to do my job anymore without some add'l tools and could not afford licenses for the aforementioned products out my of my own pocket. This was my impetus for looking at new tools in the first place.
One of the things in particular that attracted me to EA was that it clearly has more full-lifecycle functionality than anything else I've seen at any price point, much less at the very reasonable price point at which it is available. As an architect and sometimes-project manager or analyst on my projects, it's of significant benefit to me to have a single tool using a single repository for all of my artifacts and documents. I only have to learn one interface, one set of toolset conventions, and I have only one repository I have to report against. It's pretty tidy and convenient.
For the full-time architect in me, I find the core modeling & design functionality is pretty good, which seems to be a common sentiment. For the sometimes PM or analyst, I find the "ancillary" functionality is a bit of a mixed bag, but on the balance perfectly usable. I think this is where some folks may differ.
My bottom-line recommendation for other EA users would be to consider using EA's core functionality for all projects, but to be careful to try the "ancillary" functionality on small projects before attempting on a truly enterprise-scale project. If EA can't do the trick for these "ancillary" tasks on larger projects, it's no problem to scale its use back to the core and use more robust external tools for the other pieces.
My recommendation to Sparks would be to please continue to include these ancillary functions in the EA product, not to segment them off into a separate product. While I'd like to see them mature a bit more (second priority to the core functionality, of course), I'm willing to accept that an all-in-one tool will probably never be as robust as a purpose-specific tool.
For me the all-in-one nature is a significant product differentiator, and I value the benefit that it provides me on certain types of engagements.