The spider has two components:
1. Send a HEAD (and repeat with GET)
2. Ignore response

The 1 can be replaced with a direct --method=HEAD
Repeat functionality is doubtful: all webservers supports the HEAD.
Only some APIs that generates a response may not support the HEAD.
But a GET response to them would be an overkill because the response generation may be heavy.

The 2 is actually a useful thing e.g. you just want to send a request but not interested in the response to keep resources.
This would be better than output to /dev/null because wget can close the connection instead of a full download.

I think that a proper solution would be to allow mutual usage of the spider with all other options:
1. If the --method specified use it but ignore response.
2. If specified --post-data or --post-file then send a POST as usual but again ignore the response.
3. If none of the above is specified then make HEAD and then GET but discard response as usual.

The --content-on-error option should disable the response discarding.

This will make the logic plain and backward compatible.

Currently I'm working on the BusyBox wget clone and to keep logic simple and plain and code small this is a best option.
It would be great if GNU wget will work like that.
Even simple error message about spider and post-data conflict takes a space precious for embedded devices.

You are right. The combination of both options doesn't make much sense.

Using a POST request with --spider seems to be dangerous as it leads to unexpected data / state on the server side. So this i not an option.

Silently doing a GET request is also not what someone would expect.

But not allowing the combination removes some degree of user's freedom of choice. I am split.