Important to know with smart bulbs: do you have them paired directly to Hubitat? Smart bulbs (or at least Zigbee ones, which most are) have a well-earned reputation as poor repeaters. They may drop messages from non-bulb devices, possibly because they were designed for lighter-weight Zigbee Light Link (ZLL) networks and the stress of having to route on a Zigbee Home Automation (ZHA) network overworks their limited resources. It seems like you have a mix of Zigbee devices on your network (the plug-in dimmer is probably ZHA). Oh, and some background if this doesn't make sense: Hubitat is ZHA. Most smart bulbs are designed for ZLL networks, e.g., Philips Hue, and per spec will fall back to ZHA if unable to find a ZLL network to join. I think the Osram ones actually just plain ZHA if they're recent enough (an unfortunate circumstance since that means there are few options out of this problem). This problem is not specific to Hubitat--it's a problem with the bulbs, but you may see it manifest itself differently (or be lucky and not at all) on different Zigbee networks due to the routes all your devices choose to use, which is not under user control.
So, I'd first be extra sure that any problem you think you're having with Simple Lighting isn't actually a problem with the bulbs (or your Zigbee network "thanks" to the bulbs). It seems quite unlikely to be Simple Lighting to me given that you say the bulbs appear to show what you expect on the device edit page (I could be wrong, but I think that optimistically updates here even if it doesn't hear back from the device).
If this is your problem, there are unfortunately not any good ways around it. With ZLL-capable bulbs, many people just keep them on a separate network like Hue (there's Hue Bridge integration in Hubitat). Adventurous users (I've seen at least two) have just bought a second Hubitat hub for smart lights and "linked" it to the first one using Hubitat's apps designed for hub linking (or a new community-created alternative). If you're up for replacing the bulbs themselves, Sengled bulbs are Zigbee but don't repeat, thus avoiding this problem.
Do you mean that the lights don't turn off if motion originally caused them to be turned on between the "only between" restriction, but motion didn't go inactive until outside that time restriction? If so, I'm actually not sure how the app is set up to handle this case. I wouldn't be surprised if that is correct. If you always want them to turn off (any time of day) but want them to turn on but only within certain times, two instances of the lighting app as you suggest may be necessary. (I think Bruce has looked at adding a couple features to a future version, but I'm not sure if this was one of them. Actually, you might not be able to turn the lights off with the current version of Motion Lighting if Motion Lighting didn't originally turn them on, so you might need to use Rule Machine. This would be any easy rule to create, but RM can be daunting for new users, so ask for help if you need it!)
This I'm not sure about. I've never used more than one at a time. The integration is still considered a "beta" last time I used it, so I guess problems aren't totally unexpected. Do you always want all GH devices to speak? If not, you can probably work around this issue by using a community app like Speaker Central to only send TTS and whatnot to devices you want (which you can configure to be enabled/disabled based on motion, switch states, time, etc.). See: [Release] - Speaker Central
