It's an interesting idea but QA of the form itself would be a nightmare. When you are testing your forms for production, part of that process includes testing the form with varying amounts of data in the barcode all the way up to full capacity. As you have probably noticed, when the barcode is not filled to capacity the "extra" space is used up by the barcode rendering engine to enlarge the module size which can increase read rates (better than error correction actually). This is a better facility to provide higher read rates than changing the size of the barcode.
One problem I still see today is people creating half-paged barcodes thinking that this increases the capacity of the barcode when in fact the PDF417 specification gets maxed out around 1,000 characters (with appropriate error correction and sizing).
Script-wise you could resize the barcode yourself depending on the data contained in the form but you will probably notice design-wise that the changing barcode size provides you with a slightly different look and feel on your form so it's not consistent for your users or more importantly, your decoding process.
So, while probably worth experimenting with to test your scripting skills, I would not recommend dynamically resizing barcodes. However, what we have done frequently on projects is increase the number of barcodes on a form to support additional data. This keeps the pages looking consistent and the module size and error correction is also consistent on all the barcodes.
