A few people have replied saying Meta lobbying, but the bills Meta is known to have lobbied for seem to be the ones that require actual age verification that would tend to increase the amount of personal data Meta gets.
Meta's lobbying spending is cited for states not doing that kind of bill, but that's their total lobbying spending in that state.
These new bills in the style of the California one do not require any actual age verification and don't give any information to sites or apps other than the age range that whoever made the user account on the device entered.
It is essentially just requiring a simple parental control mechanism be provided by the OS which provides a way for parents to set age ranges for the accounts of their children and an API that apps that need to check age can query.
On a Unix or Unix like system this could be as simple as having the command to create a user account ask for age or birthdate and store that somewhere (maybe a new field in /etc/passwd) and then adding a getage() function to the standard library that apps can call to get the age range for the current user.
From the "we want to slurp up everything we can about you" point of view usually associated with Meta it is not obvious why Meta would support this approach.
Age checks can broadly be divided into 3 categories.
1. Done entirely on the local system, with only the result being revealed to the app/site that is asking. Age information comes from the owner/administrator of the system. I.e., the parental control approach.
2. Done using the local system and some external source of age information like your government. Only the result is revealed to the app/site that is asking.
3. Verification is done directly with the site that is asking, or through a third party. You have to supply sensitive documents like your government ID to the site or the third party.
#3 is terrible for privacy and anonymity. The red state laws tend to be in this category.
#2 depends on the details. There may be ways using the timing of the communications between your system and your ID supplier (e.g., your government) and the communications between your system and the site you are proving ID to that could allow the site and the government to get more information that you want them to. There are cryptographic ways to prevent that, especially if the device has a hardware security module. It thus comes down to with #2 that you really need to look at the details.
I'm not sure if any US state is taking this approach. The EU is, with cryptography to make it GDPR compatible and allow anonymous verification. Google and Apple are also working on such systems.
#1 is basically equivalent to the "Are you 18+" dialogs on many adult web sites, except moves to the device and the admin can if they wish prevent non-admin users from lying.
It is not really surprising that blue states are tending more toward #1, especially considering that several of them are among the states that have the strongest state privacy and data protection laws.