Does this limitation greatly reduce usefulness of
canister_post_init()?
Yes. I think the driving motivation behind a canister_post_init() hook (or whatever we end up naming it) is specifically to await cross-canister calls. If you just want to execute non-async code I’d imagine you would just add it to your init() or postUpgrade() methods. It’s specifically the async stuff that we’re trying to provide a handle for.
To provide a concrete use case, consider the need to seed custom randomness. This requires making a cross-canister call to the management canister’s raw_rand() method. You’d most assuredly want that to complete before you attempted to use random in your other canister methods. If other methods start getting hit before the randomness is fully seeded it could cause significant problems.
Seeding randomness is just one example. I imagine there will be many scenarios where external data is needed to get a canister into the correct start state.
Furthermore, when asking about how to guarantee async code happens before other messages, the currently accepted solution is to add a guard clause inside each update method. I see the canister_post_init() hook as the replacement to those initialization guards, so I think it must provide the same level of assurance.