Yeah, typo on my behalf ... VBUX == VBUK (already updated/edited in my previous post).
------------
As for the comment about the VBUK index not being important ... it's actually quite important.
The original post is showing no analysis of any VBUK indexes.
Had the optmizer chosen the VBFA table first, and then nested loop join to VBUK, the VBUK table (sans any indexes) would have to be table scanned multiple times. Due to the size of these tables the optimizer would choose to table scan VBUK once as the first/driving table, and then use an index to repeatedly access VBFA.
Now, since both the 'good' and 'bad' query plans show VBUK being accessed first ... I could see where it might be tempting to say the VBUK index doesn't matter ... but eliminating any table scans of VBUK (as in the original post) is always desirable if/when an index can be used instead (as your MANDT='300' query results are showing).
------------
Now, as for the live client (MADT = '300'), notice that the optimizer does find an index it can use for the VBUK table (ie, index = VBUK~0). And with said index you get a much better query plan (primarily due to not having to table scan any tables).
At this point it's not clear (to me) if you're working with 1 or 2 different databases, eg, live/production (MANDT='300') and dev/test (MANDT='210').
Due the lack of VBUK index consideration for MANDT='210' I'm guessing you're dealing with 2 different databases and, again, I'm guessing your dev/test database (MANDT='210') is missing the VBUK.VBUK~0 index.
If you are in fact dealing with 2 different databases then I stronly suggest you run sp_help <tablename> against both tables in both databases, then compare the results. In particular, pay attention to the indexes defined on the VBUK table in both environments to see if you're missing an index in the dev/test (MANDT='210') database.
------------
As for the optimizer choosing your new VBFA~ZVB index when MANDT='300' ... the detailed analysis is showing slightly better cluster ratio stats for this new index (as compared to the VBFA~0 index).
I'd probably want to run a reorg on your VBFA indexes (in the dev/test environment == MANDT='210'), then update the index stats; objective would be to see if better cluster ratio stats on the new index will improve your index selection for MANDT='210'.
Also notice that the selectivity for MANDT='300' is now 1 (as opposed to 0 for MANDT='210' => indicating no rows for MANDT='210'). As Simon and I have both indicated ... your stats are likely not-up-to-date for the VBUK table in the dev/test env (MANDT='210'), so running update index stats against VBUK in the dev/test env (after making sure you have all of your indexes) would go a long way towards helping the optimizer pick a more efficient query plan.