There are many reasons why the IV could be expected as an input parameter:
- it could be to let the user use his/her own random number generator, possibly because the device has none (as G_G has already stipulated)
- it could be to allow for creating larger ciphertext (as ArtjomB has already mentioned) by using the IV to contain the last vector
- it could be to let the user use a deterministic method instead of a random number generator (e.g. a random permutation of an encoded non-repeating counter for CBC or just a counter for CTR mode encryption)
- it could be that the API doesn't allow for multiple return values, in that case the IV could be prefixed to the ciphertext, but the developer could have solved it by using the IV as parameter instead
- it could be to keep the encryption/decryption calls symmetric (you need to specify the IV to the decryption routine somehow)
- many protocols have specific requirements for the IV and it is a good idea to allow all possible protocols (this is basically the flexibility argument of ArtjomB with a specific reason)
It may also be that there is no specific reason at all. We cannot look into the minds of the engineer that created the device.
Supplying an IV over a public channel does not have to pose a problem, but it does raise questions about the security of the appliance.
Note that for chaining blocks in CBC it is required that the device does not pad the plaintext before encryption. If the intermediate plaintext is padded somehow then the result after concatenation would not be the same as the ciphertext that would result from a single call.