Well I hate to say this, but it looks like the documentation is wrong, and it wouldn't be the first time, eh? Remember, the documenters are not necessarily the chip designers.
For one thing, the image you refer to looks plain wrong. On figure 12 it shows the upwards arrows indicating the data transfer from the I2C stream into the device for the entire transaction. Well, that's a write not a read. I think they copied and pasted the previous figure and changed the 0 to a 1 in the R/~W position, and nothing else (note how everything else looks the same).
They say on page 7:
Thus, a read is initiated by first configuring the MPR084’s command byte by performing a write (Figure 12). The master can now read ‘n’ consecutive bytes from the MPR084, with the first data byte being read from the register addressed by the initialized command byte.
Now I would interpret that as: send the command byte (address pointer) using a write, and switch to a read (which by the I2C protocol requires you to send the 7-bit address again, there is no other way) to get that address's contents back. Because it says "performing a write" and then "read 'n' bytes back". And that's exactly how other devices (like EEPROMs) work. You write the (memory) address and then read back the contents.
eg.
Wire.beginTransmission (SLAVE_ADDRESS);
Wire.send (cmd); // send command byte (slave register)
Wire.endTransmission ();
Wire.requestFrom (SLAVE_ADDRESS, (byte) 1); // get a data byte back (switch to read mode)
byte value = Wire.receive (); // get that byte from the buffer
Subject to testing of course. But I don't see how else it can work.