Is the whole idea of restricting access to a class's public functions in different ways for other different classes just silly altogether?
Yes and no. Bear with me.
Restricting access to a specific class is silly. While it is important to separate a class from the implementation of its dependencies, it's arguably more important to separate a class from the details of the class dependant on it.
For this reason, it's also silly to name your interfaces as if they are a link between the two classes. They're not.
To the calling class, as Euphoric points out, the interface is "I need to be able to do this ... I don't care how it's done." The name should reflect that. ie. Rather than an interface between ProductService and SqlProductRepository called SqlProductRepositoryForProductService, there should be an interface known to the ProductService called ProductRepository ("I need to be able to save a product and I don't care how"), which is implemented by SqlRepository.
But SqlRepository may also be able to store Orders. And in this sense, it DOES make sense to limit access FROM ProductService to SqlRepository so that it can only store Products. OrderService may access the SqlRepository through a new interface called OrderRepository.
Why bother, you ask? Why not simply access the class, or an interface that gives you access to the whole class?
Because it might be that, once SqlRepository has grown beyond control, you want to break it down. Perhaps into a SqlMembershipRepository (which might handle users, groups, roles, etc) and a SqlManufacturingRepository (which might handle products, components, etc) and a SqlSalesRepository (which might handle orders, customers, etc). If you've allowed everything access to all of the SqlRepository, you might find this a much tougher task than simply breaking the class into three and implementing the same interfaces that the Services always needed. Especially true if you have several classes that need to save a product.
Or, and this may be the most important point, you might want to change the way you handle Sales only. For some reason, you might decide to store it in a file, or in a NoSql database.
If you've kept your interfaces segregated, you only need to implement the ProductRepository interface on the new NoSqlRepository. If you kept it as one interface, you would have to implement SaveOrder in the NoSqlRepository (even if it were a blank method, because it was never used) and leave the implementation of SaveProduct on SqlRepository.
Suddenly your entire abstraction between services and repositories would make no sense. Another developer may come along and write some code that will store an order. There is a very good chance that they'll accidentally call the empty SaveOrder method on the NoSqlRepository, instead of the SaveOrder method on the SqlRepository. And they may be very confused when that doesn't work.