p2p – Why are there no responses to signaling messages?

Most features are actually initiated by the receiver, in which case all feature negotiation does is permit (but not force) the other side to use a particular feature:

• BIP144 (“Segregated Witness (Peer Services)”) lets a node announce support for segwit serialized transactions/blocks using the NODE_WITNESS service flag. All this means is that the other side allowed (but not forced) to request blocks and transactions including witness data. It would be bizarre – but not impossible – to permit the other side to request witness data from you, but never ask for witness data yourself.
• BIP152 (“compact blocks”) are negotiated using sendcmpct. Ignoring high-bandwidth mode, sendcmpct allows (but does not force) the other side to request BIP152-encoded blocks. It is perfectly possible to announce BIP152 support, but then never request compact blocks. The high bandwidth mode is a feature on top, which is effectively equivalent to a blanket “auto-request compact blocks” for future announced blocks until further notice.
• BIP111 (“NODE_BLOOM service bit”) instructs nodes that support BIP37 bloom filters to set that service flag. All this means is that the other side is permitted, but not required, to use BIP37 filtering features. One can announce NODE_BLOOM without ever using the other side’s filtering features (in fact, this is the case for Bitcoin Core today running with the -peerbloomfilters option).
• BIP133 (“feefilter message”) adds an optional feefilter message a node can send to inform the other side it is not interested in transactions with a feerate below a certain value. There is no negotiation for it, and the message is available whenever both sides indicate protocol version 70013 or higher. There is no problem with honoring incoming feefilter messages without ever sending them.
• BIP157 (“Client Side Block Filtering”), like BIP111, permits but does not force a node to announce support for the filtering feature. One can support BIP157 but never use the other side’s filtering feature (or care about it being offered).

In some case the feature is sender-initiated, but can still be negotiated separately in both directions:

• BIP155 (“addrv2”) is negotiated using a sendaddrv2 message, which permits (but does not force) the other side to send addrv2 messages instead of addr messages. From my reading, it is not an error to not send sendaddrv2 yourself, but still honor one received from the other side.
• BIP130 (“sendheaders message”) lets a node tell its peers that they can (but are not forced to) announce new blocks using headers rather than using inv. It is possible to not send sendheaders but still honor requests from others to receive block announcements using headers.

So I think your observation is rather the exception than the norm. There are a few features which are all-or-nothing, in that they only work if supported by both peers, which then force different behavior on both:

• BIP330 (“Transaction announcement reconciliation”, the protocol change side of Erlay) is negotiated using sendtxrcncl, and only takes effect when both sides support it. In this case this is a hard requirement for the protocol as it is fundamentally bidirectional: instead of announce->request, both sides build sets of to-be-announced transactions, and then they run a set reconciliation protocol between those sets. This simply makes no sense unless both sides opt into it.
• BIP324 (“Version 2 P2P Encrypted Transport Protocol”) fundamentally changes the protocol itself spoken between peers. It is announced using a service flag (prior to connection), but the connection attempt itself is already distinct. Earlier iterations of this idea involved starting the protocol normally, and then negotiating an upgrade, but this interfered with an important privacy design goal of the protocol. The only option is having the protocol be encrypted from the very beginning, though old peers can be detected and supported by reconnecting with the old protocol.
• BIP339 (“WTXID-based relay”) is negotiated using a wtxidrelay message sent in both directions. When that succeeds, both sides must announce transactions using wtxids instead of txids (but may still request using txids).

More fundamentally, the purpose of feature negotiation (rather than mandatory upgrades) is allowing client software to opt into what features they want to support individually. I don’t think there is much point in adding protocol complexity to cater to the specific use case of only supporting a feature in one direction. If an implementation already bears the complexity cost of implementing the feature, why wouldn’t they want to use it?