Adding on one aspect to things others have mentioned here.

I personally have both ports/URLs opened and VPN-only services.

IMHO, it also depends on the exposure tolerance the software has or risk of what could get compromised if an attacker were to find the password.

Start by thinking of the VPN itself (Taliscale, Wireguard, OpenVPN, IPSec/IKEv2, Zerotier) as a service just like the service your considering exposing.

Almost all (working on the all part lol) of my external services require TOTP/2FA and are required to be directly exposed - i.e. VPN gateway, jump host, file server (nextcloud), git server, PBX, music reflector I used for D&D, game servers shared with friends. Those ones I either absolutely need to be external (VPN, jump) or are external so that I don't have to deal with the complicated networking of per-user firewalls so my friends don't need to VPN to me to get something done.

The second part for me is tolerance to be external and what risk it is if it got popped. I have a LOT of things I just don't want on the web - my VM control panels (proxmox, vSphere, XCP), my UPS/PDU, my NAS control panel, my monitoring server, my SMB/RDP sessions, etc. That kind of stuff is super high risk - there's a lot of damage that someone could do with that, a LOT of attack surface area, and, especially in the case of embedded firmware like the UPSs and PDUs, potentially software that the vendor hasn't updated in years with who-knows-what bugs lurking in it.

So there's not really a one size fits all kind of situation. You have to address the needs of each service you host on a case by case basis. Some potential questions to ask yourself (but obviously a non-exhaustive list):

• does this service support native encryption?
  • does the encryption support reasonably modern algorithms?
  • can I disable insecure/broken encryption types?
  • if it does not natively support encryption, can I place it behind a reverse proxy (such as nginx or haproxy) to mitigate this?
• does this service support strong AAA (Authentication, Authorization, Auditing)?
  • how does it log attempts, successful and failed?
  • does it support strong credentials, such as appropriately complex passwords, client certificate, SSH key, etc?
  • if I use an external authenticator (such as AD/LDAP), does it support my existing authenticator?
  • does it support 2FA?
• does the service appear to be resilient to internet traffic?
  • does the vendor/provider indicate that it is safe to expose?
  • are there well known un-patched vulnerabilities or other forum/social media indicators that hosting even with sane configuration is a problem?
  • how frequently does the vendor release regular patches (too few and too many can be a problem)?
  • how fast does the vendor/provider respond to past security threats/incidents (if information is available)?
• is this service required to be exposed?
  • what do I gain/lose by not exposing it?
  • what type of data/network access risk would an attacker gain if they compromised this service?
  • can I mitigate a risk to it by placing a well understood proxy between the internet and it? (for example, a well configured nginx or haproxy could mitigate some problems like a TCP SYN DoS or an intermediate proxy that enforces independent user authentication if it doesn't have all the authentication bells and whistles)
  • what VLAN/network is the service running on? (*if you have several VLANs you can place services on and each have different access classes)
  • do I have an appropriate alternative means to access this service remotely than exposing it? (Is VPN the right option? some services may have alternative connection methods)

So, as you can see, it's not just cut and dry. You have to think about each service you host and what it does.

Larger well known products - such as Guacamole, Nextcloud, Owncloud, strongswan, OpenVPN, Wireguard - are known to behave well under these circumstances. That's going to factor in to this too. Many times the right answer will be to expose a port - the most important thing is to make an active decision to do so.