The current documentation for the getMore command describes maxTimeMS in the following way:
Optional. Specifies a time limit in milliseconds for processing operations on a cursor. If you do not specify a value for maxTimeMS, operations will not time out. A value of 0 explicitly specifies the default unbounded behavior.
This is an accurate description of the option as it pertains to other commands, but for getMore specifically maxTimeMS behaves differently.
Firstly, the option is only applicable to getMore commands associated awaitData cursors, and the server will return an error indicating so if it is used in a getMore against a non-awaitData cursor.
Secondly, the option determines how long the server will wait for new data to be available to an awaitData cursor before returning an empty batch. It is unrelated to limiting how long an operation is allowed to run for before returning an error (this is what the option is used for in other commands).
Thirdly, if no maxTimeMS is specified in a getMore associated with an awaitData cursor, it will wait for data server-side for a default amount of time, which I believe is 1 second. The command will return after that with an empty batch if no new data was received.
For context, this option is typically specified by users via the maxAwaitTimeMS option in the drivers, most often in the context of change streams. For example, here is the Java driver's documentation of the option if used with a find command.