After adding the annotation in 7.0 M8 with #35244, we've run into questions and issues.
There is is extensive feedback under #35244 by @DanielLiu1123 for a start in effect that the annotation is not a must-have, but comes with plenty of drawbacks.
In an application that shares HTTP interfaces between client and server, putting a "client" annotation on the shared interface is a problem for the server side that may accidentally create client proxies. Creating sub-interfaces is then necessary, but not ideal.
Support for both a centralized @ImportHttpServices approach and a distributed @HttpServiceClient annotation on the interface means that the if the central scan finds an interface with a client annotation, it has to choose between the centrally provided group and the group from the client annotation, and there is no good way to decide. The central scan could skip the interface as we chose to do for that reason, but that leads to other side effects where a client annotation accidentally added on interface leads to difficult to understand behaviour.
The idea with the "client" annotation was to provide an easy on-ramp, and while it's intuitive for a small number of interfaces, it becomes problematic quickly as the number of interfaces grows. However, there is no clear path to the more scaleable central config approach. You just have to switch the approach at some point.
The simple cases were not the problem we aimed to solve. If you have only a small number of interfaces, it's easy enough to configure anyway. Given the challenges we've run into at this stage of the milestone phase, we've decided not to include such an annotation in 7.0.