Disagree you may, but I regret that your perceived understanding of both network protocols and VPNs are fundamentally flawed.
For the OP, providing that the VPN client is configured for no-split-tunnelling, the use of a VPN protects all traffic (both encrypted and unencrypted traffic alike) between the VPN client and the Commercial VPN gateway. The public-access WiFi network is the least-trust/high-risk network upon which threat-actors can readily intercept and manipulate unprotected “in-clear” traffic.
Extending my earlier example, DNS traffic (from which sensitive data can be derived - and provides address resolution for access to internet resources) is natively an unencrypted protocol - that is being transmitted “in clear”. This traffic can be intercepted and altered - potentially returning false DNS responses to the originator. This can, by example, lead to malicious DNS redirects or profiling. For this example, a VPN tunnel will inhibit interception, monitoring or alteration of the natively unencrypted DNS protocol. Adding clarification, unless otherwise mitigated, the DNS traffic protected by the VPN from interception is visible to the VPN Gateway Operator as you suggest - but this is no different to the situation that occurs with your (presumed trusted) ISP.
If privacy and security of DNS is a concern, and/or monitoring by a VPN operator or ISP is a concern, this traffic can be protected from interception and monitoring by other measures described in my earlier response. That said, in adding this protection, this shifts trust for this element of network traffic entirely to the DNS resolver.
Moving to encrypted TLS/SSL traffic, this is encrypted end-to-end by PKI - and is neither accessible to actors present on the local network, the VPN Gateway, an ISP, or other operators along the full network path. Any attempt to decrypt and re-encrypt traffic for onward transmission will visibly break the CA trust-relationship, alerting both the source and destination. As such, the TLS/SSL end-to-end encryption remains secure regardless of whether a VPN is being used or not.
Unencrypted protocols can be protected by additional measures to provide assurance of integrity end-to-end - and/or with additional encryption - but these measures are likely beyond the capability of novices. This is where Apple’s own Private Relay Service adds a degree of useful protection, being easy to enable without in-depth knowledge of network and routing protocols.
To be clear, the purpose of a Commercial VPN is to protect traffic over the least-trust segment of the connection - to which other hosts on the local network have immediate and otherwise unmitigated access to unencrypted traffic originating from other client devices.
Different measures are necessary to protect the security and integrity of traffic over the full path - requiring the use of various techniques and mitigations - each being targeted to provide protection against a specific risk or threat, combining mitigations as necessary. A VPN is neither intended nor capable of protecting the entire network path, but is but one element of an effective security and privacy solution.
Security and Privacy are always an exercise of trust - and importantly in whom you have least trust. For public high-risk networks, VPN adds useful protection from high-risk threat - but offers little additional benefit when connecting via a “semi-trusted” ISP connection. For greater threat protection, a commercial VPN alone is insufficient in any setting - and this is where additional measures can add additional layers of protection.
In summary, complete security and anonymity is unachievable unless you control every element of the network path between client and resource. For a public internet connection, the first element of the network connection often presents the greatest risk - and with appropriate compensating controls, various elements of network traffic can be both protected and directed to resources of greater trust.
