I concur with @Kilian's answer, and thought I could add something to the discussion:
What your describing is how to capture what would naturally be a subclass situation in OOP and map that to the relational model.
In OOP, you could have an event (non-recurring), and a subclass recurring event. Or an abstract event with two subclasses of one-time event and a recurring event.
As another example, take a notion of employee records. In OOP we'd have perhaps an abstract employee with two subclasses, one for the CEO who, by definition, doesn't have an identified employee manager, and all other employees who must have one other employee as manager. (Or we could do away with the abstract class).
In relational systems, this kind of simple subclassing causes a lot of headaches, and probably the best mapping is to use a single employee table with a manager field (fk to self), and allow NULL for the CEO's record's manager field.
Codd describes two uses of NULL: "missing and applicable", and "missing and not applicable". The former means it would be valid if we had the data (we just don't have it), while the latter means that this column does not apply to a record of this type.
Sadly, the two usages of NULL are not distinguished in SQL databases.
(Further, there is no formal indication of what the real type of a row is, you just have to infer it from the nulls in the optional columns. If there was, we could perhaps say that the column must be NULL for row(s) of type CEO, and must not be NULL for regular employee rows.)
As @Kilian says, there is no well-agreed upon best practice here.
However, if you were to pose the your question from an OOP perspective, I think you'd find answers recommending using subclassing.
So the issues in my mind is one of mapping to relational. In relational mappings of such situations, NULL is commonly used for optional fields that don't apply because of (sub) typing. In this case, NULL would mean Codd's Missing and Not Applicable because for a one time event the recurrence field is not applicable.