Think of it like this:
--dir-cache-time is the maximum age (timeout) for the information. After this it is forced to refresh from cloud it every time you want to read that metadata
--poll-interval Is the interval that the mount asks "Hey Gdrive, did anything change on your side since I last time I checked at ((time)) ?" If Gdrive has knows about changes since then it will send a list of those changes and the mount will integrate these info the cache to make it up to date again. This is much more efficient that re-listing everything of course - although the polling request in itself does use an API call each time it checks.
The reason you have two flags that kind of do similar things is that not all cloud systems support polling. These will have to only rely on --dir-cache-time. Gdrives do support polling, and so they can use very large (practically infinite) --dir-cache-time and get their updates though polling instead.
set --dir-cache-time to a very large time
set --poll-interval to the maximum time you want to wait before detecting changes that were made by third-parties
You may also consider using a high --attr-timeout . While dir-cache-time caches the folders, --attr-timeout caches all the file attributes like size, modtime ect. and this is often even slower to re-list.
However, if you do you must be aware that this can carry the risk of data corruption in very spesific instances. Specifically - if A lists some files, then B changes the size of that file - and then before the polling interval picks up on that change, A tries to modify that same file, then corruption can potentially occur.
So if you have a multiuser environment where files are frequently edited by multiple users then this may not be a good idea - at least not unless you do some kind of extra revision backup with --backup-dir or something
But if dealing with only one or a couple of uploaders not usually modifying the same files and you run a low polling rate (as low as 10s may be workable as thats about 1% of your API quota) then the risk will be quite low.
Lastly, if I one of your 2 systems only reads from the drive then it is perfectly safe. The possibility of corruption can only happen with at least 2 independent sources modifying files (sizes specifically). If this is the case then use a high --attr-timeout freely and enjoy a mount that feels almost as snappy as your regular harddrive