I2C SoC explicitly not multimaster
While multi-master I2C may seem like a superset of single-master I2C, it's perhaps most useful to think of them as though they were separate, since a lone master is allowed to act in ways that would be illegitimate for a bus-sharing master, and such actions can recover easily from failure modes which would be harder to deal with in a bus-sharing system.  For an I2C master to coexist with other masters on the same bus, it must include support in hardware and software for such coexistence; this support must, among other things, to include time-out logic to handle the scenario of another master starting communication and then getting reset while SDA and SCK were released (or getting reset while SDA was released and releasing SCK as a consequence of the reset).  In that scenario, neither master would be allowed to communicate until both had seen SDA and SCK high for sufficiently long as to conclude that anyone who had held the bus must have "died".  Lone-master I2C would not have such an issue, since there will never be any transactions pending it doesn't know about, and time it doesn't want a transaction to be pending it can reset the bus by releasing SCK and SDA (if already asserted), waiting for SCK to go high, and if SDA is low at that time, asserting SCK and restarting the procedure (which may be necessary at most nine times); once SDA and SCK are both high, it can begin the next transaction by asserting SDA.

Because of the differences in design between shared-bus and lone-master firmware, most lone-bus applications would require substantial rework to coexist with other bus masters.  Since multi-master hardware would be useless without corresponding firmware, I don't see any need for a device which will be used as a lone master to include the hardware necessary for multi-master arbitration.

BTW, one thing I've not seen supported in hardware, but which would IMHO be useful, would be a means of performing shared-address multi-slave arbitration.  The signalling protocol would make it easy for a I2C device to support a "prepare to read device IDs" write address and a "get next device ID" read addresses.  The former command would "activate" the read-ID mode of all devices receiving it; the latter would cause any device whose read-ID mode was active to try to output its ID (dropping out if it lost arbitration to any other device); any device which successfully output its ID would deactivate its read-ID mode.  Under such a scheme, a master which output a "prepare to read device IDs" and then issued multiple "read device ID" requests would receive back the IDs of all connected devices in a fashion much smoother and easier than that used by one-wire protocol.