Something that may have got lost in this discussion: your typical VPN architecture takes your original traffic (which may or may not be encrypted) and tunnels it from one endpoint (your computer or your router, whichever is the actual endpoint) to the other endpoint (the VPN server provided by the VPN service provider).
Beyond the other endpoint, as the original traffic makes its way to the actual host that you wanted to communicate with, if the original traffic is not encrypted then it can be intercepted by any party who can insert themselves into the route from the VPN server to the final destination.
Even if the original traffic is encrypted, metadata can be gleaned by the malicious party. A sophisticated malicious party may even be able to perform traffic analysis to correlate outgoing traffic from the VPN provider with incoming traffic to the VPN provider e.g. if it is not very busy and does not take countermeasures.
All of this assumes that the VPN provider is completely trustworthy and does not reveal any information.
This all still applies when you spin up your own VPN server.
Many security protocols would allow you to negotiate a null cipher on a tunnel. I don’t know what the exact state of play is with applicable VPN clients but in an ideal world you would configure your VPN client to demand a minimum specification of cipher.
One legitimate reason to have a secure connection but not have encryption is if you only want integrity (not confidentiality) on the connection. So you care to ensure that a malicious party cannot alter the traffic in transit but you don’t care whether the malicious party can intercept the traffic. This could make sense if the content is public anyway, and is not sensitive enough that the fact of accessing the content needs to be kept confidential.