Cannot really be said in a general way. With a lot of effort probably all of those could lead to more serious things, but not easily in a platform and setup agnostic way, i.e., you probably need time and be able to try multiple times to get you a realistic chance.
If it's not possible to try multiple times (e.g., your try crashes or runs into some other protection mechanism (no-execute flag on page set, return address validation, ...) then there's, again depending on the specifics of the bug and it's context, a very slim chance to achieve a (arbitrary) remote code execution, or something similar serious, realistically.
Also, for side channels you often need to be able to run code on the host, in some way, at which point it's probably not really interesting to exploit through VLC (as it runs normally as non-root/non-admin user anyway). Else, you'd need to be able to get some VLC responses which have a code-address related measurable characteristic (normally time-deltas), not sure if VLC can be forced to leak such infos from remote.
VLC can also connect to a remote host and play a network stream. You could probably infer delta-T through the time it takes VLC to request the next chunk of your video/audio stream.
But still, that's a long way from exposing the address of useful gadgets or other potentially sensitive information...
Also, for side channels you often need to be able to run code on the host, in some way, at which point it's probably not really interesting to exploit through VLC (as it runs normally as non-root/non-admin user anyway). Else, you'd need to be able to get some VLC responses which have a code-address related measurable characteristic (normally time-deltas), not sure if VLC can be forced to leak such infos from remote.