I can only comment on this from a NORMA perspective, not EF, which I haven't needed to touch since its beta days. One of the final student projects at Neumont (2007 timeframe) was to directly generate entity framework xml from an ORM model, without needing to import from the database. I'm pretty sure I still have the code, but it was against a beta version of the framework, not quite finished, and never got checked in.
For NORMA, the
problem challenge with subtype columns in a supertype table is that absorbed subtypes can be asserted, derived, or semi-derived depending on the situation in the model. For a normal subtype that actually plays some roles, you will generally get some additional columns in the supertype table. If an asserted subtype plays no roles, then you currently get nothing. Obviously, this is bad on my part. However, it is also generally considered poor modeling to introduce a subtype that plays no roles, so this is a relatively rare occurrence.
In an absorbed subtype, the 'isOfSubtype' column would be asserted if the subtype plays no roles beyond the subtype relationship, semi-derived if it plays no mandatory roles, and fully derived otherwise. Of course, the derivation is easiest if a mandatory played role is actually in the table (as opposed to in a join table, for example). Basically, I've punted this issue until I can generate derived columns because I can only do it half-baked without derivation support. So, if you have a subtype with no role players, use a unary fact type instead and you'll get an absorbed column, or separate the subtype table.
Having said that, if you have a separated table for the subtype then I see very little reason to have an 'isOfSubtype' column in the supertype table. In a query, the check is trivial and fast with an indexed join to the subtype table. If EF can be told to recognize the subtype without adding the noise in the database, then by all means do it.
Of course, you need to be very careful when translating ORM subtypes into anything in the OO space to be sure that the OO subtypes mean the same thing as in ORM. ORM subtypes imply that the subtype and supertype are the same instance and always of compatible conceptual types, whereas the OO subtyping paradigm can be used behaviorally, allowing an object to look and act like a duck even if isn't really a duck. The impedance mismatch is not as bad with single-inheritance systems (VB, C#) as with multi-inheritance, but it still requires care in translation.