Yes, that’s correct; to be precise, I meant to say as decided by whoever is managing the inbox discovered through crawling attributedTo. Usually this is only 1 level higher and the object is an actor.
As for implementer precedent, there is a broader general precedent for checking attributedTo if the current object doesn’t directly have an inbox: Like and Announce! These two activities uncontroversially pass through the attributedTo property to find an inbox and deliver there. It’s reasonable to invert this logic and say “it is possible to Like an actor directly”, i.e. make an actor the object of a Like activity. Would anyone argue that only non-actor objects can be liked? In the case I’m describing, you would usually check attributedTo, but you don’t need to do this because an inbox is directly present, and probably there isn’t even an attributedTo present! Overly strict dogmatic thinking would have you believe it is impossible to Like an actor because actors are distinct from objects. Of course, this isn’t true, because actors are Objects, and any Object can be an actor.
A larger observation here is that the notion of an “actor” here is not useful at all. Ultimately we should concern ourselves with trying to describe resources and behaviors. None of the behaviors in ActivityPub depend on anything except the activity type and the corresponding special collection it manipulates. For the most part, the behaviors are all isomorphic wrt Follow/Like/Announce and followers/likes/shares. The sole difference is that the Follow flow is defined such that you add the Activity.actor instead of the Activity to the collection, similar to how a Like.object might get added to your own liked collection.