Looking at your requirements...
Part 1 - Excel has no real problem getting xml data or doing web service queries. I was doing that sort of thing back in Excel 2002.
part 2 - Probably you're right that the data integration would be syntactically nicer and probably better optimised in C# - linq is very handy. But it depends on what that integration is.
part 3 is definitely vba territory, all the updates etc.
part 4 doing that in c# might look prettier UI wise by not opening cmd windows - but how often is the code really going to run vs how easy they are to hide.
Other considerations...
Unless you do late binding, your C# app will be version-tied to Excel (as given away by the inclusion of excel version when you add the reference). If you had a new version of Excel deployed then you'd have to update your C# app where vba would most likely 'just work'.
There shouldn't be an issue with resourcing either - you said you have C# devs and anyone who has the skills to call themselves a developer should be able to adapt pretty quickly to the major procedural languages and libraries they might reference for .net development could be in either C# or VB.Net equally - it's not like you're writing it in F#.
There's a lot to be said for keeping all the dependencies together as well since you have an excel dataset to merge in.
The biggest downside with vba is that not being compiled if you give it to someone else they might be tempted to tinker. :)
All things considered I'd suggest a VBA solution as it would be the most appropriate tool for this job. There aren't any 'showstopping issues' which would dramatically swing it either way though.