The current text of Part 3 section 4.7. https://reference.opcfoundation.org/v104/Core/docs/Part3/4.7/ says:

"
Methods are “lightweight” functions, whose scope is bounded by an owning (see Note) Object, similar to the methods of a class in object-oriented programming or an owning ObjectType, similar to static methods of a class. Methods are invoked by a client, proceed to completion on the Server and return the result to the client. The lifetime of the Method’s invocation instance begins when the client calls the Method and ends when the result is returned.

NOTE The owning Object or ObjectType is specified in the service call when invoking the Method.

While Methods may affect the state of the owning Object, they have no explicit state of their own. In this sense, they are stateless. Methods can have a varying number of input arguments and return resultant arguments. Each Method is described by a Node of the Method NodeClass. This Node contains the metadata that identifies the Method’s arguments and describes its behaviour.

Methods are invoked by using the Call Service defined in OPC 10000-4.

Clients discover the Methods supported by a Server by browsing for the owning Objects References that identify their supported Methods.
"

Part 4 section 5.11.2.2 on Parameters of the Call service says, for the objectId:
"
The NodeId shall be that of the Object or ObjectType on which the Method is invoked.
In case of an ObjectType the ObjectType or a super type of the ObjectType shall be the source of a HasComponent Reference (or subtype of HasComponent Reference) to the Method specified in methodId.
In case of an Object the Object or the ObjectType of the Object or a super type of that ObjectType shall be the source of a HasComponent Reference (or subtype of HasComponent Reference) to the Method specified in methodId.
See OPC 10000-3 for a description of Objects and their Methods.
"

• for the methodId parameter:
  "
  NodeId of the Method to invoke.
  If the objectId is the NodeId of an Object, it is allowed to use the NodeId of a Method that is the target of a HasComponent Reference from the ObjectType of the Object.
  "

My (personal) interpretation of the spec is that a Method is either a static (owner is the TypeDefinition node, doesn't have a ModellingRule) or non-static (owner is the instatiated Object node, does have a ModellingRule), but not both. Assuming this interpretation is correct, then the part "NOTE The owning Object or ObjectType is specified in the service call when invoking the Method." plus "Clients discover the Methods supported by a Server by browsing for the owning Objects References that identify their supported Methods." would mean you can either use the ObjectType (for static) or Object (for non-static) as the objectId. Which would contradict the current wording, but would have made sense with the wordings of 1.01 versions of the Call parameters, which just said:
"The NodeIdshall be that of the Objector ObjectTypethat is the
source of a HasComponent Reference(or subtype of
HasComponent Reference) to this Method."
for the objectId parameter.

Thus, I either:

A) The wording on Part 3 must be updated to reflect that there is no longer a concept of "static" Methods or somehow how to determine which methods are as such that they are not allowed to be called from Object instance. For example, the has-ModellingRule-references could be the logic. This matters for code-generating utils, e.g. you might generate static methods to a different place since the instances of the generated class type could e.g. only use the non-static ones (e.g. static methods vs. non-static would be directly translateable to static vs. non-static methods e.g. in Java code).

B) Revert Part 4 to the original 1.01 text. I assume this will not happen.

Probably the change has been made in order to support some Nano Server profiles I would assume? Or servers that wont have a Types section.

Also it is possible, that I have mistanken something plus I should mention that e.g. in Java it is technically possible to call a static method through an java-object-instance, but that in general is bad programming and would result in a compiler warning.