1) Unlike H.323 and friends, SIP is the product of rather purely Internet-orientated/IETF thinking, not ITU. It was initially designed to set up multimedia "sessions" of various kinds (few prescriptions as to what kind) over the Internet in a rather generic sense.
Aspects of "traditional phone architecture" have been painstakingly grafted onto SIP, with mixed results. Certain things that have been taken for granted for decades are extraordinarily complex to do with SIP, such as bridged/shared line appearances on office PBX systems, because ...
2) ... SIP decentralises a lot of intelligence and state, taking it out of the phone switch (or PBX) and putting it in the endpoint/handset itself.
A traditional PBX system or Class 5 subscriber switch is very all-knowing, in the way that SCCP-based Call Manager is all-knowing. SIP puts a lot more responsibility on the endpoints, leading to distributed systems challenges.
But yes, this has been a feature of Key systems since before many HN readers were born. It was easy because the PBX knew all and controlled all; it knew the calls going through itself, and just told the corresponding phone to illuminate this lamp.
With SIP, it requires an elaborate presence (SUBSCRIBE/NOTIFY) song and dance, often implemented using competing methods, and even when you get the lamps working, cross-connecting a caller to a different phone to simulate "picking up a line" is no mean feat, since the new destination was not previously a party to the dialog. This gymnastics is usually implemented underneath using "call parking", which means users must remember to "park" calls rather than merely place them on hold, and intelligence must be devised to get line keys to map to correct "parking numbers" and so forth.
It's certainly not impossible, it just becomes an incredibly overcomplicated feat of technical jujitsu for something that worked fine for ages under the old regime.
That's because SIP was very much _not_ designed for traditional telephony. :-)