What security risks does exposing the size of the plaintext entail?
Exposing the size of the plaintext has no security risks. The size of the plaintext is always considered public data. It's not done because it has limited benefit.

With a mode like CBC, you cannot encrypt a fractional block. You must pass a whole number of blocks to the encryption function. So you need padding in some form. The ciphertext is a whole number of blocks. If the ciphertext itself doesn't encode the message unambiguously, you need to pass the size separately, at least the size of the last block (or equivalently the size of the padding). In practice, that means you need at least one extra byte to indicate the size. If you do this, then the padding doesn't need to be unambiguous, so you can allow it to be empty if the plaintext happens to be a whole number of blocks. Compared with unambiguous padding, this method results in ciphertext-plus-size that's one block minus one byte shorter if the plaintext is a whole number of blocks, and one byte otherwise. So in terms of ciphertext size, it's a wash.

In terms of ciphertext and decoding complexity, passing the size separately makes things a little more complicated. The ciphertext isn't a black box anymore: the padding size needs to be sent with it. The ciphertext-plus-size can be a black box, but it's a little harder to process: the last pseudoblock is one byte longer than the others.

This scheme does have a security benefit. Since the recipient does not need to decode the padding, it eliminates direct padding oracle attacks, if done right. However this was poorly understood when CBC was in vogue: people generally followed the usual wisdom to verify everything, thus revealing information about the content of the last block. Today, serious protocol designers are well aware of the dangers of padding oracle attacks, but the solution is not to use padding at all.