In fact, the Redis protocol does not support fire and oblivion operations. With the exception of pub / auxiliary traffic, all Redis commands are mapped to the response, and there is no way to tell the Redis server to omit the response.
Now some clients (for example, StackExchange.Redis) simulate the fire and forget mode through an asynchronous protocol implementation. Actually, the "fire and forget" mode in StackExchange.Redis is very similar to the "asynchronous" mode, except that the responses are simply discarded when they are received.
Is it reliable? Well, this guarantees delivery, since TCP / IP guarantees delivery. The network will try to transmit packets (eventually packets will be retransmitted if some of them are lost), but all this is handled by TCP.
Now, if the server is turned off or decided to close the connection, the client will know when it tries to read from the socket. StackExchange.Redis may happily continue to send commands on a dead connection for a while. If you have a middletier (e.g. Twemproxy), the situation could be even worse.
In other words, fire and swell traffic is usually sent to the server, and no message will be lost on the network, but if you have problems with the server or connection, some traffic may be lost before the client gets a chance to notice this. I would call this the best behavior.