I really admire the fact that you’ve shifted your approach here. It’s easy for things to stay negative on the internet. Thanks for that. 
If the notification worked and then stopped working, it might be worth trying to figure out why that is. Virtual Fields definitely have some limitations (see below), but the issue might also be issue the content of the Notification document. Many/most fieldtype distinctions in ERPNext are purely front end, and I don’t think there’s any difference in how the server or the database treat Data and Select fields.
I definitely agree there’s a huge amount of potential for virtual doctypes and fields, but there are also some important constraints on their functionality.
As I understand it, virtual fields are implemented at the document-controller level, which means that they work with methods that instantiate document objects (like frappe.get_doc) but not with API methods that poll the database directly (like frappe.get_list). This is a significant limitation for filtering or report building, but there’s not a simple and performant way to get around it.
There’s a further issue with virtual fields with logic defined in “Options” (as opposed to logic defined in the doctype_name.py controller). I’ve always found these to be very inconsistent. They tend to work correctly on the client side (and, strangely, in API calls), but they don’t always show up in server-side calls. Something weird is happening with caching (see here for some inconclusive discussion). That may be the issue you’re seeing.
It seems unintiutive to me to send emails without a TO recipient, only CC or BCC. I just checked on the two email systems I use and one allows it and the other doesn’t. I have no idea what the spec says, but it seems like something that different email platforms implement differently. You could probably un-mandatory the field with a Property Setter, but I’m not sure how the frappe sendmail implementation would respond. It would need a bit of testing.
As far as other functionality goes, you can always extend the doctype with a custom controller class. That way, you could add your own functionality while building on the bulk of the Notification doctype’s existing structures:
https://docs.frappe.io/framework/v14/user/en/python-api/hooks#override-doctype-class
This would also allow for things like communication preferences to be implemented, of the sort you mentioned in your original post.