The problem is that in the common case case those IP addresses are useless and serve no purpose. Broadcasts get broadcast because they are sent to broadcast MAC address. They can have IP packet with all-ones destination inside (which is different from a unicast packet sent to that same address via its unique MAC), they can have IP packet with a specific destination inside (well, maybe your ARP cache is malfunctioning, and you've forgotten the proper MAC address, but not the fact the host exists?), they can have arbitrary data (because you've invented our own protocol). You also need to call a different function or set some flag to make broadcast happen. It is possible that early IP stacks relied on a dedicated high-level broadcast address to prevent the need to handle all kinds of underlying networks in programs, but I'm not sure.

(Trick question for the exam is whether broadcast traffic received by new host with assigned address of .255 would be a problem.)

HOWEVER, if you want to broadcast something at a remote network, you need to have dedicated network broadcast IP addresses. Unfortunately, even RFC 919 from 1984 thinks it is not a recommended mode of operation. But imagine that we could get "ip/subnet" from DNS, send broadcast to a distant server farm, and receive response from anything that responded. Instead of DNS-based service discovery, we would have a single A record, and finally put that IANA port number database to use in port-based service discovery.