Currently, publishing supports QoS 0 or 1; subscribing only supports QoS 0.
Why? In MQTT, the way QoS 1 works is that every message is individually ack'd. So the receiving end (the client, for subscribe-side messages) sends an ack to the sending end (the server for subscribe-side) each time it receives a message, and the sending end keeps track of the set of unacked messages (or a cursor on the first unacked message). Then after a timeout or after a resume the sending end resends.
This is exactly how Ably works on the publish side (from client to server). Hence we directly support QoS 1 for publishes; it directly maps across to our native protocol. But on the subscribe side the native Ably protocol does something a bit different - we have the client keep track of the last message it received, and tell us which it was when the client resumes. So it doesn't map perfectly across.
So for now we only support QoS 0 for subscribes, because it's the level that maps across best to our native protocol. But it's on the 'more reliable' end of the QoS 0 spectrum, if that makes sense. For example, for QoS 0 the broker is entitled to just never attempt to send messages you missed, but we do support session resuming, and after a resume we will send you every message we couldn't deliver before. Just with the caveat that since the client doesn't tell us the last message it recevied, there's a chance that given network issues, there may be messages that we think we delivered to the client that the client didn't actually receive, so those may be missed.
We may still implement QoS 1 (or even QoS 2) support for subscribing in future, if there is customer demand for it. If you would be interested in this, please get in touch with us.