Hello Oliver,
just my thoughts on your request:
The integration of hapi-fhir into IPF is quiet hight, but i don't think that every single hapi release will cause API breakings that really require a new IPF release. Consuming Services and application can simply define their own dependency management and include the dependency management from hapi (hapi-fhir-bom) of a version they want (to override any transitive dependency definition), as long as a API compatibility is verified. Hapi 6.6 is a good example: I don't see there any incompatiblity to IPF 4.6, all tests seems to run fine - so it should be safe to use IPF 4.6 and HAPI 6.6 in your client application.
Nethertheless, any PR with for updating to a new HAPI release is welcome to also see if API breaking changes are present and provide a solution in case of a incompatiblity. I think releases should still be done if a meaningful featureset is provided and not based on a hapi release trigger.
But let's hear the feedback from other's as well.
Best regards,
Thomas