A pass object is one member's pass on the Google side. Where a class holds what every pass in a program shares, layout, branding and program-level content, the object holds what belongs to one person: their identifier, points balance, tier, offers, barcode value and the credential a Smart Tap reader collects. Every object references a class, and both are prefixed by the program's issuer ID.
The object is a record in Google's API, not a file. Nothing is signed, downloaded or reissued to change a member's pass: the issuer writes new values to the object, and Google delivers the change to whichever devices hold it. That is the structural difference from Apple, where a pass is a signed PKPass file and updates arrive through device registrations and a push update.
An object exists before the member has it. The issuer creates it, then hands the member a save link that says which object to add. The link can also carry a full object definition, in which case Google creates the object at save time. Either way, the object is what persists afterwards, and creating one twice with the same identifier is an error rather than a second pass.
Objects also carry state. A pass can be marked expired, inactive or completed, which is how Google Wallet retires a pass without deleting it, and grouping information, which is how several related passes stack into a pass bundle. A member never sees an object ID. They see the pass, and a wallet platform keeps the object and its Apple counterpart in step from a single pass definition.