2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
I'll grant you the consistency argument. I'm all for consistency, but
that's the ONLY valid reason you've stated.
Even then I think this part of the argument is fairly weak. In Bar::class, the context of Bar is always a class name (either short due to do namespace or use statements, or long fully qualified).
$object is not guaranteed to be an object, it could be anything (int, string, etc) or nothing (null). using ::class for a variable, I'd argue, makes for less consistency. What would the replacement be for non-object variables? An error, exception, or false, or string type? At least in "Bar::class", you'll always get a string representation of what the fully qualified class name resolves to.
That said, the argument could be made that since static::class, self::class, and parent::class fall into the same category of potential runtime resolutions that $object::class too should be supported.
-ralph