Seems like this is the new trend right now :-) Phil Brammer has posted a rebuttal to my original post. Here are my answers:

Bad Errors:
You have to understand though, that this isn’t .Net.  SSIS has many components/engines at work that obtaining the correct error isn’t always at the heart of the SSIS engine.  It could be a database error.  It could be an ADO error.  Whatever it may be, I agree, some are cryptic, but I’ve generally been able to diagnose my errors.  And if there is an error I don’t know about, I contact the community and finally Microsoft through product support.

Error handling is a key part of any platform, this should be a first level concern, that it "isn't always at the heart of the SSIS engine" is a serious issue. Errors happens, and I need to know the entire chain of issues in order to figure how to fix it. To clarify how important that is to me, I am using .Net because it has exceptions, rather than HRESULT.

Random Errors:
The fact these are random should banish this item from your “SSIS 15 Faults” list.

The product sometimes gives an error, for no deterministic reason, and you consider this a non issue?

Keeping track of what it shouldn’t:
Never had this happen.  NEVER.  NEVER, NEVER, NEVER, NEVER.  Did I make my point? 

Yeah, your point is "It works on my machine".

Sorry excuse for deployment:
I don’t understand any of the points made here.  Deploying to a server has never been a problem.  It is in the manual that metadata cannot change between databases/tables.  So if you’re moving to an environment that has its metadata different than another, you need to reconcile that first. 

I had the package fail with validation errors when moving to production when the DB schema was identical, invalid meta data errors. I don't want to reconcile anything, the schema is identical for the tables that I am working on. And let me point out that "it is in the manual" carry little weight with me, I am disliking the need, not disputing its documentation.

UI Formatting instructions:
Ah, well, what would you say if the SSIS dev team decided to make SSIS packages binary?  THEN WHAT?  At least you have an XML file that can be parsed.

Uh, you do realize that for all intents and purposes, the file is binary, right? The fact that it happens to be XML based doesn't make it human readable, source control friendly or diffable. All of the above are critical to development.

Bad interoperability:
Is your Oracle example an SSIS problem, or the Oracle driver’s problem?????????

That is probably an SSIS error, but see my previous point about bad errors to know what I am not sure.