In the AEAD scheme described in https://www.rfc-editor.org/rfc/rfc7539#section-2.8.1, the aad and cyphertext are padded to be a multiple of 16 bytes in length. Why is this necessary? Does it provide any advantage over simply not padding the data?
It is the authentication - which uses Poly-1305 that needs the padding; the padding does not expand the ciphertext. The Poly-1305 operates on blocks of 128 bits. The padding is applied so that Poly-1305 can always process full blocks of input. Afterwards the the padding is discarded - it is not kept with the ciphertext.
During verification the padding is reapplied, otherwise the calculated authentication tag would not be identical with the one that was kept with / is part of the ciphertext.
In the case of Poly1305 it seems that the additional authenticated data (AAD or just AD) is padded separately, instead of concatenating the two and padding the combination of the two. This makes it possible to calculate the AAD component independently of the ciphertext component of the authentication tag, as DannyNiu's answer indicates.
Note that in practice a single block input buffer will be used within the implementation of the Poly-1305 function. Implementations will pad the buffer instead of the actual input. Discarding consists of clearing the buffer - if it is cleared at all, it can also ignore the data in it.
One advantage it provides, is that you can calculate the authenticator for associated data AFTER you've calculated authenticator for ciphertext, which may not be fully available at the time of calculation.
Although canonically, you should have all your data ready at the invocation of encryption API, ChaCha20-Poly1305 is designed as a "high throughput" AEAD mode just like GCM, which intend to make such computation possible.