Ive been using alembic in production since they first added it to Houdini and there are several ways to keep things procedural, and like everything in Houdini, they all work but its not always clear which one to use.
So using the alembic archive:
All that the alembic archive does is extract your transform hierarchy into Alembic transform nodes, the actual geo is inside a houdini geo object and is being read with an alembic sop with transform to worldspace set to off (Because you want it to be in local space prior to the xforms applied to it).
[Alembic Archive] > [Alembic Transform] > [Houdini Geo Object] > [Alembic Sop Reading Geo]
If you make sure that 'Build Hierarchy With Channel References' is on, then all the corresponding alembic xforms and sops will be linked to the top alembic archives file name path and frame/fps. Meaning that if you change paths, it should update, but all you have to do in order to update without rebuilding is link to the reload geometry inside the alembic sops. Technically it should update when you change paths, but we all know that can be a little hit and miss considering how it loads into memory.
Something to note about motion blur. If you were to say import or object merge from your alembic archive into a fresh sop and do not specify the correct transform or in most cases use 'into this object' (Which i have done plenty of times for various reasons) keep in mind that you lose the transform hierarchy so your motion blur will change. This also applies to just reading in an alembic through sops. Although this really only matters for objects that have transform
Now if you are lighting something like a character and its just a bunch of deformation motion blur anyways then that doesn't really matter because you will need to geo sample more than once anyways.
An example where it would matter would be something like this:
Say you have a cg ball that is animated globally and has a local rotation on it as well. If you can work it out so that you just use alembic xform nodes then you can make a really efficient pipeline where you have the default position or skinned position of the geo saved out as a packed prim or alembic or .obj or w/e and you are just applying the exported xform data to it. However for things like a character it would probably all be deformation in local space anyways so the transform stuff is irrelevant.
When it comes to material assignments you can use the data tree 'object appearance' pane to assign materials quickly to the houdini geo nodes, but if you want it to be more procedural you will need to use a packededit or do something like i mentioned before where you build a subnet asset that has a reload button for just the alembic sops so that you don't need to 'rebuild'. My experience is that the alembic xforms update fine on their one once you change the path. As a third option you could always create a python script that generates the link to all the reloads on the alembic archive itself. Keep in mind the transform hierarchy naming convention needs to be perfect.
Now if your less worried about being able to use transform data, such would be the case with a character, or if your planning to render with high geo samples anyways then you can just use an alembic sop and assign materials via packed edit or material or w/e.
Note about groups: by default the alembic sop does not create any groups for you (which may be confusing, especially if someone spent a long time making a nice structure in maya or wherever the alembic is coming from). Go down to primitive groups and you can decide how you like the alembic to partition your groups out. Typically I use the 'Transform' method because that is typically what people decide to use in maya, and I the shape method also would generate much longer names.
This is all from experience using alembic, so if I said something wrong and somebody else knows better I would appreciate the correction!
Hope that helps.