Why bother with even parity?
A single parity bit can only check for the presense of single or odd numbers of bits in errors so expecting it to detect when a peripheral is disconnected is probably expecting too much.
However, many systems will produce a continuous series of 1's when a peripheral is not present and this can be achieved with a simple pull-up resistor on the returning data line. If there was actual 8 bit data being returned by a connected peripheral then the parity bit would be zero for decimal 255 being transmitted. So even parity can detect when a peripheral is disconnected under these circumstances.
If odd parity were used, 8 high bits (decimal 255) would result in a high parity bit so rendering odd parity useless as a means of detecting loss of peripheral chip.
Horses for courses.
Parity, or any block error detection, is intended to detect errors within a data transmission itself. Parity is not designed to detect whether or not data transmission is taking place.
Given a transmission line, there are several different kinds of concerns. The two which are relevant here are: 1) outright failure of the line itself, and, 2) block data errors within a particular transmission. Others less relevant are, for example, incorrect line voltages, protocol errors, or security errors. Parity helps with 2 but not 1. For a subsystem on either end of a transmission line to cope with 1 (outright failure of a connection), another protocol feature is required.
The error detection rate of a single parity bit is often higher than 50%. Exactly what that rate is depends on the heuristics of the data segment in the protocol. Say you have a packet, (MSB) 1011010111011110, and there is an single bit error in the last transmitted bit, the parity check would fail and correctly reject it packet. Similarly, if you had a data error in the first bit (the parity bit), the packet would be rejected.
Performing this check in hardware is extremely simple and requires no complicated processing. It is useful in applications with relatively low bit error rates to weed out things like clock skew or clock signals generated by processors running garbage-collected software stacks.
SPI is a physical link protocol that designed for short electrically connected lines where the single-bit error rate doesn't much depend on the loss of the line. If you're running something across a lossy line, you're going to need something way more robust than parity. This isn't really what SPI does.
To check whether a device is still connected, try something higher in the stack. By comparison, TCP/IP (IP, specifically) doesn't specify parity bits while many of the 802.x Ethernet specifications do. IP does, on the other hand, have a complicated, "are you there?" protocol. What are you running on top of SPI? The answer to data link management is probably there.
There's no obvious benefit of even parity over odd. In communication and storage schemes, the parity polarity (odd or even) should be selected to trap the most likely or highest-occurring failure modes.
As you say, an unresponsive target or broken data receive wire may well result in a MISO line stuck high or low.
When communicating even numbers of bits, such as bytes over SPI, an odd parity bit would detect a fault in this all-1's or all-0's data but even parity wouldn't.
However, there's no such clear winner when communicating an odd numbers of bits, such as in your application with 15 bits over SPI. Even parity would detect a fault in the all-1's case but miss the all-0's case. Conversely, odd parity would detect a fault in the all-0's case but miss the all-1's case.