What security risks does exposing the size of the plaintext entail? For this question my focus is exclusively on symmetric block ciphers (with a particular interest in AES256 in CBC mode).

I have read much discussion on various ways to pad the plaintext so that the length of the input to the encryption algorithm is a multiple of the blocksize.

The real problem here is not padding to a suitable size (which, by itself, is trivial), but rather undoing such padding after decryption.

One very simple scheme for undoing the padding is to store the length of the (unpadded) plaintext in a header section, unencrypted.  Then, after the ciphertext is decrypted, the raw result is truncated to this saved length.

Since this simple solution is never mentioned in discussions of padding (I've consulted several textbooks), I have to assume that there are some very serious problems with it, but these problems are never spelled out, and they are not obvious to me.  What are they?
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.