In many cases, I expect the coordination between client and server on which SubscriptionTopic to support will be done at dev time, not at run time.  I.e., a server would publish a list of topic canonicals they support, along with documentation online somewhere.  A client will consume that documentation, and write code to work with the topics they care about.  

In this case, SubscriptionTopic.read and search seem unnecessary for a server to support.  

Additionally, a client that is doing development to support specific types of topics likely won't have authorization (an access token) to query the FHIR server SubscriptionTopics.  Or at least not the production FHIR server.  They might query a non-PRD or sandbox server to get topics during dev, but that would not be the same server they'd be interreacting with in PRD.

In short, I think the SubscriptionTopic discovery workflow as proposed doesn't feel real-world (or at least it won't be for all implementers, i.e., EHRs).  And the subscriptions framework page should at a minimum allow for dev-time topic discovery by relaxing the run-time conformance requirements on servers in https://hl7.org/fhir/uv/subscriptions-backport/2024Jan/conformance.html