Think of the uses or a normal server operating system: what is it needed in normal operation? Say you are connecting a serial terminal (for logins), or you are connecting two computers to each other, for data exchange, for example via SLIP or PPP. Those are the common use cases for serial ports. If you enable hardware flow control, then those modem control signals (RTS/CTS) don't need to be monitored from the user process, nor manually set. If you disable hardware flow control, then those signals are irrelevant. Similarly, if you set modem control, then DCD/DSR/... are automatic, otherwise irrelevant.
What I'm saying: The functionality of manually checking and setting the modem control signals is not commonly needed; for the rare case that needs them, a synchronous call is sufficient. The use case you want (which is to build a hardware monitoring device) is not what the serial stack is intended for. I fully believe that Linux has it, but that's because Linux has a wider spectrum of use cases which is outside the normal server computing model, for example laboratory data acquisition.
Another remark: Don't be so dismissive of polling. What time resolution do you need? It would be hard to argue that you need anything better than 10ms. So try putting the ioctl for checking the modem control signals (I think it is TIOCMGET, but that's from memory) in a loop that is executed every 100 times a second, and measure the CPU consumption. My educated guess is that polling is a perfectly adequate technique here. For example: At home, I poll two pressure sensors that are connected via serial ports. Reading their value requires an interestingly complex serial protocol (I use ModBus), and I do that 20 times per second. To make matters worse, the whole code is written in Python. It uses 3-4% of the CPU. In efficient C, it would probably be an order of magnitude faster.
