The Requestor Pool table fields are explained in the link you have provided at page 45 and 46.
Regarding the points you have raised please consider that the following metrics are updated each time an attempt to borrow a Requestor is performed. This should clarify the "surprising" values observed in your screenshot.
MostIdle: Indicates minimum load on the service package up to this point (E.g.: the greatest number of idle objects over the life of the Requestor Pool). This value is updated BEFORE a borrowed Requestor is retrieved from the pool
MostActive: Indicates maximum load on the service package up to this point (E.g.: the greatest number of active objects over the life of the Requestor Pool). This value is updated AFTER a borrowed Requestor is retrieved from the pool
LongestWait: Indicates the longest time a Service Request waited for a Requestor to
become available. This value is updated AFTER a borrowed Requestor is retrieved from the pool and provides the longest wait time as observed from the Service Package.
Please note that this value can be greater than the Maximum Wait defined in the corresponding Service Package Pool which instead indicates that the maximum amount of time the pool should block before throwing an exception when the pool is exhausted (E.g. how long a new request should wait in case all the Requestors in the pool are already allocated and the Maximum Active Requestors limit is reached)
Hence having 10 Idle Requestors in a pool with a MostIdle value of 9 means that at the time of the
snapshot (i.e. when the SMA Service Requestor Pools page was loaded) there were 10 Idle Requestors in the pool but each time a Requestor was borrowed from the pool the Idle Requestors were less than 10.
Having 37 most active, 100 max active, and 14 longest wait means that the pool used at most 37 Requestors concurrently (which is within the 100 Maximum Active Requestors limit defined in the corresponding Service Package Pool) and at some point a Service Request effectively waited 14 seconds before getting a Requestor (this time is most probably related to the creation of a new Requestor)