4.5.1: According to [1] Zigbee 3.0 is safer than older versions such as Zigbee 1.2 (HA), amongst others because it supports out-of-band ways of providing the key used when joining the network to the TC.
4.5.2: According to [1], the Centralized architecture is more suitable to higher security environments, because it supports install codes for joining the network.
4.5.3: As explained in [1] in a lot of detail, a crucial part of Zigbee security is how devices join the network and learn the network key. For Centralized architectures, the safest way to do this is using an install code (ex. QR code on packaging of sensor), which is pre-installed in the sensor and transmitted out-of-band to the TC. For Distributed architectures, the safest way is to use pre-installed link keys, which should be manufacturer or application specific (i.e. not the known global link key "ZigbeeAlliance09").
4.5.4: See above.
4.5.5: As mentioned in [3], to reduce the attack surface of the system, devices (both joining nodes and the TC / router) should only enter pairing mode with user interaction.
4.5.6: As noted in [3], the network key is known by all devices in the Zigbee network, some implementations use the same across different systems, which is a security risk.
4.5.7: Periodic network key rotation lowers the risk in case of compromise (the network key is known by all devices in the Zigbee network), and also answers some concerns about long-term reuse of the same key for AES encryption, as noted in [3] (pg. 15) and [1].
4.5.8: Adapted from [3] and proposed as an alternative to MAC address whitelisting - gives users the power to inspect their network for malicious Zigbee devices.
Since the conversation in https://github.com/OWASP/IoT-Security-Verification-Standard-ISVS/pull/77 died off, I'm submitting a fresh pull with the proposed Zigbee requirements :)
Sources:
Rationale: