It's useful to keep the 16 million IoT devices you have running on WiFi segregated a bit.

Thanks for the correction on the the broadcast address, btw. The details are important.

At home, I have 172.16/12 scoped out for my cluster subnet and just use the second and third octet to denote service function. It's excessive scoping, but it's an internal scope for a private network and broadcasts are generally contained to the cluster network. It would be trivial to split that into a 172.16/16 if I ever had the desire. (Speaking bluntly, it really doesn't matter much in this case. I'll need to split it out to keep Longhorn traffic segregated later, but it's not an issue now.)

The rest of the network is reasonably scoped out across 192.168 ranges and chopped up across a few VLANs.

My addressing scheme is split into "public" and "stay the fuck out", with most 172 addresses being the latter. At home this is great. In a large network, scoping out such a large 172 subnet could be detrimental. ("It depends" on the detrimental bit and requires proper planning and understanding about why subnets were even built into IPv4 from the get-go.)

Edit: Most addressing is static on my cluster network, with DHCP only handing out addresses based on MAC address. The 172 subnet has very restricted dynamic IP ranges.

Regardless of what is what, it's a scheme I recognize and that is the more important bit.

It might also make you really grumpy if you decide to use a VPN or containers - those often use 10/24 subnets and having an overlap with your LAN can make things spicy.

Yeah that's fair. Maybe OP is planning a nonsense amount of IoT devices and cameras? or they just want to use some unorthodox IPs like .255 or .0 for fun 🤷