No timeout is defined anywhere in the rs.remove() path:

• Shell side (src/mongo/shell/utils.js:1938): it sends db._adminCommand({replSetReconfig: c}) with no maxTimeMS, and unlike rs.add/rs.reconfig it doesn't go through rs._runCmd, so there's no retry/timeout wrapper either.
• Server side (src/mongo/db/repl/repl_set_commands.cpp:433 and :452): a non-force reconfig calls awaitConfigCommitment() twice — before installing the new config and after. Both waits use write concerns built with WriteConcernOptions::kNoTimeout (replication_coordinator_impl.cpp:3210, :3217), i.e. wait forever.

So the only bound is the operation's own deadline from maxTimeMS, which rs.remove() never sets — meaning the command can block indefinitely waiting for config/oplog commitment to a majority. If it does time out you'd see MaxTimeMSExpired converted into CurrentConfigNotCommittedYet (:435-437), but that only happens if you supplied maxTimeMS yourself.

This is related to an inquiry raised by technical services here: https://jira.mongodb.org/browse/HELP-98148