Does INFORMATION_SCHEMA always contain up-to-date metadata?
Yes, the data is up-to-date.  But don't read too much into the numbers.

InnoDB, especially, preallocates space for future rows.  So, it is quite possible to look at the exact size of a table, insert dozens of rows (maybe even thousands), then look at the size again -- and see exactly the same Data_length and Index_length.

When you first create an InnoDB table and insert one small row, the data length will be 16384 bytes (one 16KB block).  As you add more rows, eventually that block will overflow, and another block will be added.  Later (as the table exceeds some threshold), the table will grow in units of (I think) 8MB (an "extent").  This will allow even more rows to be added with no change in disk footprint.

Also, was the table created with innodb_file_per_table ON or OFF?  This controls whether the stuff goes into the communal ibdata1 file or the table's own .ibd file.

And, as @jkavalik points out, DELETE and UPDATE and ALTER can mess with the size, again not necessarily in predictable ways.

Edit

Those are the "disk footprint" size.  Compare to what you can see looking at the filesystem.

A 1-row table with one 4-byte INT takes at least 16384 bytes of disk space.  If you are saying that "4" is the real size, then I have been answering the wrong question.  I say that 16KB is the real size.

There is overhead for each column, for each row, for each block, for BTree structure, for each extent, for indexes, etc.  And InnoDB allocates no less than 16KB at a time.  And room for 'undo' copies of rows.  Hence, "4" turns into "16384".

As a "Rule of Thumb", if you add up the data sizes (4 for INT, etc) of the columns in a row, multiply by the number of rows, then multiply by something between 2 and 3, you are likely to get the "size" of the table.  (The 1-col, 1-row example, of course, is an end-case that exceeds 3x)