The reason is partly XML related: it is easier to add the modifySql to one changeSet definition in the XSD rather than all the change definitions, plus remember to include it for all future change types.
Also, in the end it should not make a large difference since you should generally just use one change per changeSet. If you have multipe createTable changes in one changeset, and the first executes but the second fails, liquibase cannot mark the changeset executed, but cannot role back the first create table change on most databases. Since most DDL statements autocommit, it is safest to only use one change per changeset. We support 0…* createTable changes per changeSet so as not to limit people, although you should avoid it.
Since the modifySql is on the changeSet tag, it does apply to the whole SQL. If you need to modify all statements, you may be able to find a way to replace the “)$” regexp string with “) engine INNODB” or something else clever.
I made add support for per-change modifySql in the future, but there is a better option in liquibase 2.0: you can write you own class that extends the createTable sql generator and have it append the engine innodb string yourself, even add your own XML parameter to control the engine. With that power, the modifySql may not be as necessary anymore.