Efficiciency of multiple small triggers versus one large trigger on SQL Server
Community wiki answer:

You already sound like you know the right answer. The best approach is the one that has the trigger code run the fastest with the least amount of code. If it were me, I'd have one trigger per action. Will there be duplicate code - absolutely - but it saves you for when anything needs to be changed and can be customized per situation.

You could try both and then simulate load to see which you like/performs the best. Aaron Bertrand found there was observable additional overhead with multiple triggers performing the same operations, but YMMV.

However, a couple dozen transactions per minute doesn't sound like a tremendous amount of activity. Maintainability 'might' be able to justify a small amount of overhead. There are numerous advantages to using separate 'single-function' triggers. As you indicated, they have a single purpose and can be individually tested (by different people), enabled, disabled. Isolating the processing into separate 'single-function' triggers 'might' reduce the risk involved in future maintenance.

Of course, final testing of the individual triggers cannot be by different people, as you need to ensure the triggers work properly in unison. And, while future maintenance of smaller chunks of code is logically easier, you cannot ignore the other triggers when making future changes, as something that causes no issues in trigger A could completely mess up what trigger C is doing.