You have to be careful about what they are asking here. I am responding to this on a higher level given the behavior of the commands you are talking about.
Spectrum will pull back multiple OIDs for any given poll cycle. This is used to populate the various things that it needs to do. By default Spectrum does NOT pull back a whole pile of OIDs (unlike eHealth or PM) from a device as it is primarily interested in fault management. That is NOT to say that it can't, it is just that it doesn't make sense in order to perform large dumps per poll cycle when all you need to know are a few things about the device.
Spectrum will perform these queries programmatically - as in using a C call in order to perform the task. It does NOT use a series of netsnmp snmpget/walk commands.
Performing snmpget for single OIDs is incredibly inefficient and is definitely NOT what you want in a monitoring tool. You would never be able to poll all of your devices within a poll cycle if this sort of thing was done.
The snmpwalk command is something that you do NOT want to perform against a large device. The reason for this is you can easily take it down with the volume of response that you get back. I have seen Cisco ASRs auto-generate gigs and gigs of text response to snmpwalk commands (generally they die after about 6-8 hours of querying - though in the meantime the CPU of the device is affected).
I don't think that it is possible to simply "turn off" these snmpbulkget queries as it will affect EVERY device/poll that Spectrum will perform. This is, obviously, something that you do NOT want to do.
There might be someone on the forums who can respond as to what the best way to query these devices are considering a possible software issue on the vendor's end. However, I suspect that you might end up having to upgrade the Juniper to a later release that doesn't have the bug that they mention - which I can understand may not be an easy task.
Ed