Transport Packages: Why?

Thanks to Bob Ray's book, I'm able to package my own snippets, plugins, etc. into a transport package and get them installed on my sites or share them with others.

My question is why are transport packages and build scripts structured the way they are at all? Is it to give a uniform way for component authors to modify the database and the various elements? Are there other reasons? Build scripts, transport packages, and vehicles is admittedly complicated, so there must be some reason for it.

I know with WordPress, you basically commit your changes to SVN, and basically you're done: WP packages the SVN branch for you, and the updates are made available to users of your plugin. However, WP does not have any uniform way of modifying the database or site files outside of the plugin package (i.e. no distinction between files in the core/ and files in assets/ folder).

Instead of manually creating a build script to package up a component, might it be possible to unify the component structure and offload the creation of build-scripts to MODX's servers? That would require rigid adherence to a certain structure (e.g. all chunks *must* be stored in directory named elements/chunks), etc, but it's easier to structure directories in a certain way than it is to wrap your head around build scripts. Am I missing something? Or is it just that MODX doesn't want to restrict developers in how they structure their work until it gets published? Might this be ground for a packaging plugin (sorry if this is exactly what PackMan etc. do, I'm a bit slow on the uptake).

I just wanted some discussions on how and why things are the way they are -- especially as I work on the MODX vs. WordPress book, I know WordPressers are going to be baffled by the complexity here.

Thanks!