Can TMS be used to manage remote devices connecting via the Internet?

Yes, this is possible, because clients connect to TMS, rather than the other way around, which allows the connection to work over NAT translation.

At the TMS server end, you will need to set up a port forwarding rule on your Internet gateway (modem/router) so that incoming connections to TCP port 8085 (or whatever alternative port you have configured) of your public (external) IP address are redirected to the same port on your TMS server's private (internal) IP address.  You may also need to explicitly allow TCP port 8085 through firewalls, although this is typically automatically implied by port forwarding rules.

If your Internet Service Provider has not assigned you a static public IP address, you will also need to set up some form of public dynamic DNS name for your TMS server that remote clients can use to connect to whatever your server-side public IP address is currently using.  Almost all modern Internet modem-routers can be configured to log in to services provided by certain commercial dynamic DNS providers (e.g. dyndns.org, noip.com) and automatically keep a public DNS name in synch with dynamic DHCP leases.

TMS was mostly aimed for LAN use, and due to limitations of its original protocol that cannot be corrected without breaking backward compatibility, it doesn't cope with firmware upgrades over a WAN very well.  Clients must download large images (up to approx one gigabyte) from TMS in very small encrypted chunks (at most 64 kilobytes), which was fine back in the days of SSL v3 but is very slow when using TLS 1.x.  Also, historically at least, tms_client isn't/wasn't very robust when dealing with download failures.  Moreover, upgrading a large number of remote clients in this way wastes a lot of WAN bandwidth by repeatedly downloading the same data.

However, there is a way to manage these issues to minimize inconvenience.  You must still upgrade one device at each site using TMS, which could be slow and require a few attempts, but after that you can easily upgrade other devices at that site using the upgraded device as a template.  To do this, use TMS to configure the device as a PXE Server (Device->Network Configuration->Optional Services->PXE Server, configure appropriately and ensure that Purpose is set to Provisioning), then instruct other devices at the site to enter Maintenance Mode (Device->Commands->Enter/Exit Maintenance Mode).

That's all you need to do, because the default Upgrade/Recover boot mode of the Maintenance Mode image will discover the PXE server's AoE shares for /boot, /tfm and /actualroot filesystems, determine that they contain later versions of TLXOS than the ones on local storage, and provided that you have a valid paid license, will then automatically upgrade TLXOS.  The device will go offline in the TMS console while upgrading; when it comes back online, instruct it to exit Maintenance Mode (Device->Commands->Enter/Exit Maintenance Mode).  When all devices at the site have been upgraded in this way, you can deactivate the PXE Server role on the template device.

Note that it is not necessary to actually PXE boot clients - this is only required when devices don't already have a bootable Maintenance Mode image on local storage, i.e. for initial installs.  The only reason you are temporarily activating the PXE Server role is to make use of its ATA-over-Ethernet (AoE) shares, and possibly also its DHCP server (because Maintenance Mode prefers to use DHCP, and will only use a static IP address configuration as a last resort).