For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
publish BIP70 payment requests instead.

Agreed - it's not clear to me at all that this partial address scheme is actually secure. The assumption appears to be that the MITM must match the address prefix generated by the genuine merchant. But if they can do a wireless MITM they can just substitute their own address prefix/partial address, no? 

To avoid MITM attacks the sender must know who they are sending money to, and that means they must see a human understandable name that's cryptographically bound to the right public key. Displaying partial addresses to the user is not going to solve this unless users manually compare key prefixes across the screens.... which is even less convenient than a QR code.

I think it should be explained why to
prefer broadcasting payment requests over picking them up via near field
radio.

This is probably an artifact of Apple's restrictions on iOS. Only the iPhone 6 has NFC hardware and Apple don't expose it via any public API. It can however support Bluetooth LE.

Apple isn't a big deal in Germany because iPhone only achieved about 17% market share during the quarter when the iPhone 6 launched. Normally it's closer to 10-13%. Most other markets are similar. 

However in the USA, UK, Australia and Japan iOS is still a big deal and NFC is going to be seen as a non-universal solution there. At least, until Apple catches up and provides an NFC API.

It's certainly not a problem to have a working radio based broadcast system, though the theoretician in me wonders what  happens when lots of people are trying to pay simultaneously for something that has equal cost ..... e.g. buying movie tickets at a counter. NFC and QR codes prevent any kind of "oops I paid for someone elses stuff" confusion.

In practice of course Bitcoin payments are not normally popular enough for this to be a problem outside of Bitcoin community events.