More people should publish custom migration code.
I have watched @zopyx huge efforts for the University of Ghent project. Andreas can expand on this, but there is a large 'long tail' of attributes and parameters on content objects for the many different features we have and 'have had' in Plone 'the application' for generic CMS functionality. default_view, layouts, content rules, constrain_types, permissions, portlets, etc.
(I'm leaving out the custom content types for the moment. And there's also the site settings, user/groups and other control panel config.)
Depending on if you have used that core Plone functionality in the past you will or will not notice losing those settings in an ETL migration until you start testing the results in the destination site. But that only starts working when the theming and migration of the individual content types also has been done, the destination site has to be in place before you can start testing.
And considering the age of the Plone site you now migrate to 5.2, these attributes can also contain 'legacy' values from previously in place migrated core Plone 2,3,4 versions which are sometimes hard to recognise, or values that work only for your (old) customisations/add'ons. On top of that, our friend Acquisition can trick you when you query the attributes in the extract phase and fetch non existing attributes from parents. . 
The Ghent migration part has had quite some iterations to figure out the different attributes. A few times we were debugging issues in the theming, or a custom content type, only to find out that there was a special case (in custom code) which depended on a not migrated attribute. Rinse and repeat.
The end result with a working migration profile/code, be it in transmogrifier or Andreas configuration/setup it's the combination of configuration for core plone attributes, add'ons and customisations, for the Plone features used in that particular project.
If those can be split, we can work together on making the core Plone attributes/content types as complete as possible and have a clear configuration split in those pipelines where builders of a migration tool can put the custom code, it will be much easier to publish and re-use pipelines.
But that would take quite some more effort, as described above and cleaning up your customised pipe line of one Plone site and still knowing which blocks did what after many months working on a migration story is nobody's favorite community effort.
Another aspect is that a migration project always takes too long and costs too much because of 'unforeseen', so if you know you don't need portlets, multilingual or content rules, or users because of ldap, you not only skip those, but your other code also doesn't need take it into account.
We have used ETL for one large project at Zest, @mauritsvanrees adapted transmogrifier to our needs for 18 very similar sites, where all content was extracted in single large json files per Plone site and then could be loaded again. One special feature there is that the extract phase analysed which Images and Files were actually used in Documents, and migrated only those that were referenced to clean up the target site. Worked. Sort of 
this is exactly the summary and recommended path forward I was hoping for
who builds it? 
