You are correct that the QoS is at every hop but the core concept of broker based messaging is that the broker provides the QoS facilities to facilitate communication between the Publisher and the Subscriber(s).
What the blog you have referenced does not cover is the Suback, which is covered in the spec. Almost all popular brokers support it.
The function of the broker is to losely couple the publishers from the subscribers. Even when there are no subscribers online, when you publish with QoS1, you want to be sure that the message has definitely received and stored at the broker end, for the subscriber to come and consumer later. If you don’t want he broker to store the messages, you use QoS0.
Different brokers implement different kinds of storage for these messages. Most do it via some form of disk, though some such as Solace Appliances (my employer) do it via purpose built hardware in the appliance model, and via disk in the software model.
Now there could be many reasons this storage may not happen, even through the message may arrive at the broker properly (as per your correct TCP argument). E.g. the disk/storage is full or the queue is out of quota etc. There could be more sophisticated reasons, such as if the message could not be sent over to the DR site and you want to enforce strict replication, such that you reject the message even from the primary site if your business logic so demands.
In such cases, the publisher should be informed that his message has not been saved successfully at the broker. Hence the need for Puback.
Suback work conversely, i.e. when the subscribers receive the messages, they let the broker know so that the message can be deleted.
There is no ACK going between publisher and subscriber, its between publisher and broker, and broker and subscriber. That way one being down/slow does not (should not) impact the other.
HTH,
Sumeet.