It's definitely confusing, but pacemaker ignores the timeouts listed in a resource agent's meta-data. The timeouts (and intervals) in the meta-data are "hints" to the user (and UIs such as pcs) as to what's a reasonable value to use. It's expected that actually desirable values will vary by deployment and so should be tested and adjusted by the user. By contrast, pacemaker uses (in order of preference): any timeout explicitly set in the operation configuration in the CIB; any timeout set in op_defaults in the CIB (i.e. pcs resource op defaults); or 20 seconds. Partly this is imposed by pacemaker's scheduling model -- the scheduler only has access to the CIB, which currently doesn't include agent meta-data. We could consider having pacemaker save agent meta-data hints in the CIB, but that could hurt scalability in clusters with many different resource types. There's also a problem with different versions of the same agent installed on different nodes -- we'd potentially need to store the hints per node, which would be even worse for scalability. This would be considered a new feature, so it would be RHEL 8 only. (BTW, the ocf:pacemaker: agents are part of the pacemaker component, not resource-agents.)
I have thought of an implementation that could scale: instead of feeding agent meta-data to the scheduler, the controller could keep the default timeout values in its meta-data cache, and the scheduler could add a flag to scheduled actions when the timeout is the "default default" (i.e. not explicitly specified in either the action configuration or op_defaults). The controller would then override the scheduler's timeout value with the one from cache when available. Unfortunately there is still a large backlog, so I would not expect a fix in the next couple of point releases.