Because the instances are provided up front, no get-next calls are done to be able to determine the instances, like would be done with a normal bulk. The get-next messages take up most of the time; if there are 100 rows, then you need 100 calls to iterate over the instances. All cells are directly polled instead with full OIDs as if you would be polling a group of single parameters.
The downside is that you need to know the instances up front. If new rows are added to the SNMP table, then you will not know this and you could be displaying incomplete data.
If you want to use this to poll a full table, there are better alternatives such as the multipleGetBulk that doesn't iterate via get-next calls (does require SNMPv2 though), multipleGetNext to get the data row per row, or using the PollingRate feature to poll different columns at different speeds.
Also note that there is a small known issue: if you only specify one instance, then it will execute get-next messages to iterate over the instances. Add a ',' after the instance value in the subtable filter to avoid this issue.
Second note is that you have to be careful when using this, because not all firmware of the devices performs equally well when table member OIDs are directly polled. This could take up more device CPU and some devices might even return the same value (e.g. the values of the first row) for all the requested rows. Normally, the getBulk SNMPv2 requests (via multipleGetBulk) are designed by the firmware developers to poll tables in the most efficient way for the device.