уууу, класс вопрос.
Я бы тоже хотел иметь табличку сравнения, ну по типу как вот это
http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.ii.doc/start/cgpdif00.htm

Но такого вот нету.
Мда.
Interchange - вещь в себе. Абсолютно все в нем. Замкнутая система.
Активно продаваемая и актуальная.
Но - без будущего. Весь функционал, который в основном и выделял его, теперь развит и развивается в среде J2EE. Сюда, пожалуй, можно включить и process choreographer.
Interchange как раз и силен (выделяется) наличием Process Integration.

С другой стороны, Message Broker это продукт немного другого уровня. В нем относительно слабая Process Integration составляющая, более сильная составляющая трансформации данных.
Message Broker продолжает линию Application Integration, но привносит сильную интелектуальную составляющую по сравнению с MQ.
То есть если просто в случае с MQ приложение отправляет сообщения указывая "кому", то при использовании Message Broker приложения могут не указывать "кому", так как даже если они и укажут - все равно Broker может переадресовать сообщения базируясь на заданных Message Flows, то есть приложения получаются еще слабее связаны, чем в случае с MQ только.
Опять таки - эти Message Flows компилируются С компилятором, поэтому еще его называют самым быстрым в мире брокером.

Так что это игроки немного разных полей.
Я бы остановился на Message Broker с вынесением Process Integration туда, где ему и место (с точки зрения IBM)
Process Choreographer - это приложение под application server.
Но для многих случаев Message Broker будет достаточно, и при развитии системы и появлении потребности в Process Integration - вы поняли к чему я клоню. То, что уже успели сделать на Message Broker - интегрируется, перейдет под управление того же choreographer'а

Фух.
Сложный вопрос. Архитектурный.
Зависит от множества факторов.
Как и все в IT, блин....
Базу данных - и то проблема выбрать.....
А что такое база данных??? Да всего-навсего лишь небольшое "яйцо" на схеме "мира" у архитектора! Всего-лишь сервис, не более того (простите меня, базовики.....)
А тут - средство интеграции........

Опять же, у Interchange много adapters ко всяческим существующим приложениям - ERP/CRM/SCM/Whatever
То есть меньше работы если надо интегрировать уже работающие системы такого плана.
И даже MQ & Message Broker могут использоватся как транспортная подсистема при развертывании Interchange.
Но адаптеры нужны только специальные для ICS.

C другой стороны, при создании системы с нуля это не так актуально, а адапторов уже есть для Message Broker и надо думать, будет больше.
И адапторы могут быть любые от кого угодно лишь-бы MQ-enabled.

Ну и сама IBM позиционирует Broker для "...high throughput, high performance, message-based data interchange environments"
Broker легко кластеризуется для повышения производительности. Ну и MQ тоже.

По "архитектурным" особенностям - ICS это только hub-spoke, а с брокером и MQ можно строить какие угодно схемы.

И еще - сапсем забыл MQ WorkFlow как Process Integration.

Хотя MQ WorkFlow будущего не имеет. Теперича Process Server (дальнейшее развитие Process Choreographer'a наше будущее)

как вот еще подсказал costic2000, надо сделать бОльшый упор на то, что interchange все-таки более process oriented (с возможностью организации длительных бизнес-процессов)
а Broker message oriented.
Ну да, это кардинальное отличие.
Я вроде упомянул.
Ну теперь усиленно упоминаю. Все равно, есть другие, более кошерные тулзы для process oriented задач. Опять таки уже упоминалось выше.

вот совместными усилиями с costik2000 решили упомянуть еще такое явное усилие, как compensation, в Broker только мамому создавать компенсацию для отката транзакции, в которую вовлечены невостановимые ресурсы, а в Interchange есть поддержка автоматической компенчации.