The most important fact in I2C communication is that a transfer is always initiated by the master. This is either a write operation (master sends to slave) or a read operation (master receives data from slave).
The master doesn't need an address on the bus because it's always initiating every communication and it's also controlling it (by providing the clock signal).
If you wanna send information from the slave to the master, you have to take care that the master is polling the slave for that information often enough. Although there is no rule how the slave organizes the I2C transfers the most often used scheme is the register based approach. That means the slave defines some registers which the master is able to read and write. Each register has it's address, sequential reads and writes are allowed (auto-incrementing register address). Most I2C devices use this way to communicate because it naturally fits the I2C specification.
In your case for slave 1 I would define two registers, on address 0 (and 1 because it's an integer) you have threshold value, on address 2 (and 3 for the second byte) you have the sensor value. If you wanna save some register addresses you can combine the two because probably the threshold value is only written while the sensor value can only be read. How you organize the byte order (little or big endian) is on you, both have advantages and disadvantages.
What is also confusing me, with regard to EasyTransfer vs standard I2C, is the "number of bytes" when doing a request. How do I make a request to the slave, in the EasyTransfer data structure paradigm?
I wouldn't use the EasyTransfer library in your case. It only makes things more complicated and I don't see the need for dynamically sized transfers on the I2C bus.