There are a number of reasons. There are some places where the transport would not behave correctly if publisher confirms were disabled, and the only way we could fix that would be to break wire compatibility. We absolutely did not want to do introduce that kind of break.
There are also no scenarios where it’s all that beneficial to turn off publisher confirms.
Based on that, we decided to remove the ability to disable using publisher confirms.
The publish confirms were anyway used by default unless the option to disable them was used intentionally. By removing the NServiceBus option to disable them you are basically denying the ability of developers to configure the transport in a specific way that may be desirable in certain scenarios and is being supported by both the RabbitMQ server and the underlying transport client library (RabbitMQ .Net client).
For example, one such scenario is the ability to push messages to RabbitMQ, tolerating possible loss with the highest possible speed and minimal stress on the server side (RabbitMQ) in terms of CPU and network bandwidth.
Whoever is using this option, should be well aware of its consequences and looking at the changes pushed as part of the change I can’t see any optimization or other benefit of omitting this feature.
I have added some context to the PR that removed the publisher confirms API, pointing back to an old closed issue that highlights some of the problems that removing it was intended to avoid.
NServiceBus is an opinionated framework. Ultimately, we judged that the feature caused more harm than good, so we removed it. You’re free to use the RabbitMQ client directly if you need to, and you can still send messages to NServiceBus endpoints if you do.