And this output is now showing analysis of the VBUK~0 index (this didn't show up in your original post). Along with use of the VBUK~0 index in the final query plan.
Did you add the VBUK~0 index since your first post? Or were these results from running against a different database? [Would find it hard to believe that the optimizer would first ignore the VBUK~0 index, now recognize the VBUK~0 index ... ???]
----------
The fact that this query still runs slower than MANDT='300' (34 secs vs < 1 sec) is going to be related to the different indexes being used for VBFA ("Duh Mark!" ?).
As a first attempt to addressing this issue I'd try running update index statistics on VBFA.
If that doesn't help, you can either drop/recreate the VBFA indexes, or run a reorg of VBFA; afterwards run update index statistics to make sure the optimizer has up-to-date stats to match the newly rebuilt/reorged indexes. [Primary objective is to a) defrag the VBFA~ZVB index and b) make sure you have up-to-date stats]