Some definitions and assumptions:
EMM: "economically motivated maker" - defined as purely motivated by immediate largest economic benefit, not bounded by coding skill (so can implement any algorithm not limited to our codebase), not interested in any privacy concerns, and most importantly: not including the intent to either DOS or not DOS the system.
Un (x) a real utxo (index n) controlling x btc.
U'n(x) a fake utxo (index n) controlling x btc.
Assumption: the EMM has U1 ... Un real utxos, each with corresponding amount xi.
Assumption: each bot has 1 offer (note: not assuming each identity has only 1 bot, of course). this simplifies one bit of analysis, can be discarded/discussed afterwards.
Consider the EMM's potential behaviour in the two cases: 1, the current protocol without utxo commitments from maker, and then 2, with the podle commitments
He can partition these into offers in any way he likes (by defn EMM can spread offers across bots any way he likes, so restrictions per-bot are irrelevant), but more importantly: he can make any pattern of offers, not being tied to any specific utxos.
In order to attain his stated goal of economic advantage, he can consider repeating offers up to amount Σ xi (higher amounts have no effect, since he can't fill them).
If the taker requests amount R and R << Σ xi ,then the EMM's advantage increases linearly in the number of repeats, since not only is his probability increasing for each sybiled offer, but he can also fulfil the offers easily without conflicting over his utxos. If R is larger, the second part of that advantage may well be reduced: he may be included in the fill request, but unable to fulfil it (e.g. he has 3 BTC in offers repeated 10 times, Taker requests 3 of his bots to do a 3BTC join, but they can't all do it). There is the slight amelioration of ignored_makers lists maintained by Takers, which is currently a very minor disincentive, for these cases of conflict.
There are lots of details to delve into here, but it seems obvious that ignoring other limitations, the EMM is mostly incented to increase offer duplication basically without bound, certainly for smaller offer sizes.
(Note: here utxo lists are referred to but it's implicit that they're actually represented by hp2 values at the start of the JM protocol).
In this case, we can start from the EMM's choice of partition of the real utxo set; according to the second assumption, this means partition into a set of wallets, one wallet per bot. In contrast to the above he must make such a partition in advance. Which partition he chooses, e.g. [(U1),..(Un)] or all-in-one: [(U1, ..., Un)] is something entirely out of the protocol's control, however we implement it (i.e. a Maker can take 10BTC and split them into 10 separate 1BTC wallets, if he likes).
The question becomes, is there a gain to be had from repeating or adding fake utxos to this partition/set, as it is published in the offers, in !hp2 values.
Repeating is immediately rejected as it violates the rules of the new protocol. So we consider only faked !hp2 podle values.
Suppose he chose the first of the above partitions, 1 utxo per bot/wallet. Imagine 3 utxos for simplicity. He could replace:
[(U1(x1)), (U2(x2)), (U3(x3))]
with
[(U1(x1), U'1(x1)), (U2(x2)), (U3(x3))]
In so doing, he's increased the offer range from x1 to 2 * x1 , for his first wallet. But he'll still not be able to actually complete the protocol for any R > x1, so he can only gain selection advantage for cases where he cannot gain economic advantage, which by definition he is not interested in. The argument extends trivially to any further fake values.
Finally, the question of when the podle verification, which requires the utxo's pubkey, occurs (and indeed, whether we only verify the utxos used in transactions. I believe the above paragraph answers that "it doesn't matter when", but the argument is dependent on the EMM assumption. If the EMM is only interested in getting more completed transactions, he will fail to do so by any extra fake utxos.