Just to set your expectations, I don't generally look at what Debian or another package manager enables in their packages, and I don't know if any other MacPorts maintainers do that.
I don't know how Debian's packages work. I don't know if they have a concept like MacPorts variants which let the user choose which features to enable. If they don't, that would be a good justification for them enabling many features automatically, whereas in MacPorts it's a good reason not to, since not all users need all features and some of them come with a lot of dependencies.
I'm happy to enable http/2 support unconditionally since http/2 is mainstream now, even though I would not expect the lack of http/2 support to have caused many problems since I would expect servers that support http/2 to still support http/1.1 as well, although maybe I'm out of date with that expectation.
http/3 appears not to be final yet. curl's support for http/3 appears to be experimental. Looks like it could use any of several different libraries for http/3 support, none of which are in MacPorts yet, I think. If you want http/3 support in MacPorts curl, we'd have to add at least one of those ports first. Let's table that until later. Feel free to file another ticket for that, or to submit tickets or pull requests for any of those needed dependencies.
I'm happy to add brotli compression support to curl since that's also gained mainstream acceptance. The curl port already has zstd compression support enabled unconditionally.
libssh2, openldap, and gssapi support seem more esoteric to me, justifiably hidden in non-default variants. The gss variant has a comment explaining that it requires macOS gss, not MacPorts gss, and therefore it declares a conflict with the MacPorts gss and kerberos5 ports. If we enabled that variant by default (or enabled that feature unconditionally without a variant) it would cause an inconvenience for users who also had the gss or kerberos5 ports installed every time they wanted to upgrade the curl port -- at least those users who did not receive binaries from us.
librtmp support also seems esoteric, to the extent that there hasn't even been a variant for it in the curl port and I'm not aware of anyone having mentioned it before you. I can certainly add a variant for it.
