The default for the base object type (bpy.types.Modifier) is indeed False, individual modifiers don’t have to adhere to that default when they’re implemented on the C side of things, however. For example, the Displace modifier (bpy.types.DisplaceModifier) inherits from the base Modifier object type, and doesn’t override the parameter to True like most other modifiers do. Unfortunately (or… fortunately, if you’re not a fan of verbosity), the API docs don’t mention when an inherited parameter’s default value is overridden so you either need to look at the C source for it, or just figure it out empirically.
If all you want to do is turn off show_in_editmode for every modifier why not just loop through the modifier stack and set the property that way?
eg)
for o in bpy.data.objects:
try:
for m in o.modifiers:
m.show_in_editmode = False
except AttributeError:
pass # this object type doesn't have modifiers.. empties, lights, etc.
you could put that in an operator and then drop a button somewhere on your UI. it’s still a manual process but at least it’s just one click.
# test if context = bpy.ops.object.modifier_add
unfortunately there’s no true event->subscriber model in the blender api, so you have no way of knowing when a user is running an operator. The closest thing you have is the depsgraph update, or msgbus RNA subscriber system (which won’t work for modifiers, bpy_prop_collections in general).
If you really want a ‘first class’ way to handle the problem you’d have to rewrite the entire modifier panel- which is crazy, but isn’t actually as crazy as it sounds… @Symstract did just that with this addon: https://github.com/Symstract/modifier_list. Ironically, the modifier list addon lets you set certain defaults for addons, but not the show_in_editmode property. maybe you could convince somebody to add that feature to the addon, they have a thread here.