The reality is most developers (almost every developer I know) won't spend particularly much time on deciding settings for encryption - and honestly if they spent 10x the amount they did doing research they would still only base their opinions on things they find online like blog posts (not mathematics or government whitepapers).
I don't believe the approach is bad. It doesn't take the ability away from you to choose. It just adds a hurdle (vendoring the library), which imo stops a lot of bad decisions from overconfident developers.
[edit]: typo
That said, there is trend even outside of google to move away from high levels of configurability in these sort of security sensitive areas. I'd be curious what a system like wireguard lets you do in terms of bit twiddling.
OpenSSL was sort of famous for letting your turn just about every knob you wanted. Not sure that was a ton better.
And I have heard some concern that folks like apple put so much into attack surface on things like imessage (memoji's?) for messages from unknown and untrusted users (ie, new users you aren't texting with can send entire set of stuff imessage supports which is a TON vs just being text only to start). So even in other areas dialing down things might be helpful.
WireGuard doesn't allow you to do anything in terms of bit twiddling. This is one of the claimed benefits of WireGuard over OpenVPN or IPsec.
It seems then in keeping with ideas being followed elsewhere.
Casually (not a security expert) this makes a let of sense to me. If I'm copying my stack overflow code out for my security stuff, maybe have fewer footguns?
Not sure this is a terrible idea then.
That reason could be "the API doesn't allow developers to easily access the defaults" but the fix for that would be something completely different.
Even in OpenSSL you don't get that much choice in TLS 1.3 because the number of usable ciphers and key exchange methods has been severely reduced.