Topics are tricky because it's a pub/sub model. If you publish one message to the topic, all subscribers receive a copy of that message. Let's say I have a topic with 10 subscribers. Subscriber 1-9 process the message just fine. Subscriber 10 gets its message, but hits an exception. If you followed this code above for the topic, the message would be scheduled back onto the topic. However, that means not only would subscriber 10 get the retry, but subscribers 1-9 would get a copy of the retry too.
My recommendation is that for topics where you want to enable exponential retries, use the forwarding feature of Azure Service Bus. The forwarding feature allows you to forward all messages to a queue or topic subscription to another queue or topic. In the case above I created a queue in my namespace for subscriber 10. I then ran the following CLI command to forward all messages to subscriber 10s subscription to that new queue. Now I have my function fire and exponentially retry on the forwarded queue instead of the topic subscription, so messages scheduled back onto the queue don't go to all subscriptions.
az servicebus topic subscription update --namespace-name myNamespace -g myResourceGroup --topic-name myTopic --name subscription10 --forward-to subscription10queueThis does mean if I wanted all 10 subscribers to be able to exponentially retry, I'd need 10 additional queues in my namespace, and each subscription would have its corresponding queue. It's a bit more overheard, but likely your best bet if you want to be able to schedule a message to a subscription-specific queue.
The other very viable option would be kicking off a Durable Function orchestration instance to manage the retries of a message. It could attempt to retry the message for you and manage state between retries and would work for both queues and topics.