Not exactly, but probably close enough for most cases. 
In the event you care: it’s actually an 8-bit field where the “first” (highest) bit represents S0 (10000000 in binary = 128 in decimal) and the the last three bits represent S2 Access Control, S2 Authenticated, and S2 Authenticated, respectively. I assume the bits in between are reserved for future expansion. So, you’ll get different decimal values out of the resulting binary values/bits. If you only have exactly one grant, you’ll get something like:
| Class/Bit #: |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
= Decimal: |
| None |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
| S2 Unauth |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
| S2 Auth |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
2 |
| S2 AccCtl |
0 |
0 |
0 |
0 |
0 |
1 |
0 |
0 |
4 |
| S0 |
1 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
128 |
But if you have multiple grants–like the dimmers that will probably do S2 Authenticated plus everything “below” that by default–then you can end up with other values. For example, two possibilities:
| Class/Bit #: |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
= Decimal: |
| Auth+Unath |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
3 |
| S0+Auth+Unauth |
1 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
131 |
So, that’s how you get 131. Theoretically, that should work with Association to the S0 bulbs since both the dimmer and bulb have S0 in common, but some people have reported issues when everything doesn’t match (I can’t attest to either outcome or the other; just repeating what people have said and what should work). And my recommendation would be to skip security on the bulbs entirely since they only support S0 for reasons you’ve probably already discovered, so I guess this doesn’t really apply in that case…just some history.
No, that is handled at the hub level. A couple hub firmware versions ago, they removed the choices in the S2 popup (possibly because people were getting confused about what grants to check or not). Now you can either “Confirm” or “Skip,” where “Confirm” will use the default grants (and prompt for the DSK if necessary) and “Skip” should avoid security entirely.
However, this popup would have never — and still won’t — appear for S0-only devices where the device requests S0 during pairing. This is a limitation of the “official” Silicon Labs Z-Wave 700 SDK that Hubitat is using. Devices can work around this by providing a different pairing process for S0 vs. non-S0, which Inovelli recently added to their bulbs, but it does require some precision, and a secondary controller is still probably the easiest way to avoid this. (The other option for the vendor would be to add S2, avoiding this entirely, and now required for newly certified devices.)
With an S2-capable device like the LZW31(-SN), you used to be able to un-select any or all S2 grants and use only S0 if you really preferred that (assuming the device itself still supports S0; I’m not sure if the spec requires this). But that’s probably the worst of all possible ideas, since S0 can be pretty chatty on your network, and unless you really want it, it would be better to just go non-secure.
