i2c read error but probe succeeds
As a generic question, it makes no sense, as there is no common standard for higher levels of communication on I2C bus. It is bit better for SMBus (message format standard on the top of I2C specification), but most chips does not support SMBus standard. You must read and understand datasheet for particular device before using it.

The i2cdetect and i2cdump commands are heavily guestimating, and you are supposed to take the warning seriously and be aware what are you doing.

In your particular case, the default probe method for address 0x1a is to send device address with write flag set, check for ACK from device and STOP the communication directly. So you have learned, that the device @0x1a acknowledges its address, nothing else. Then, i2cdump in default (byte) mode works by sending single byte to device followed by repeated START condition on I2C bus, re-addressing in read mode and followed by single byte read. This sequence is repeated with incremented initial byte over and over. Your output shows, that the device replied with NACK somewhere during this sequence. Possible points (based on I2C bus protocol) are either after writing first byte or after re-addressing in read mode.

That said, you have mentioned your particular chip is WM8985. When you open the datasheet, page 88 and on in particular, you can see that this chip expects 16 bits of write data, and there is no read functionality mentioned at all. So yes, @linuxfan is right the chip is write only device. Moreover you should communicate with it by sending 16 bit long write blocks.

Back to the original generic question. It is well possible, that devices which are read-able fails to return data when (default) i2cdump command is run. For various reasons, but probably simply because access mechanism "write 8 bit register address, read 8 bit of register data" is not valid for this particular device, and you have to start read by some specific procedure described in the datasheet.