Without knowing how the underlying tracker technology functions, I cannot say that it uses literally none. I doubt you can either. They measure peers/seeders/leechers per torrent. This requires polling, this is not free.
I can. Welcome to my wheelhouse. A user who is not connected to a tracker does not consume any of its resources, because that user is not connected to the tracker. The tracker tracks connected users. There is no reason to track anything else. It is not concerned with anything not talking to it (it can't be; its purview is "active clients in the swam," which, by definition, an inactive client cannot be). In fact the tracker doesn't actually care about "users" in the first place; private trackers use authentication tokens which they validate (once or periodically) against a backend (which talks to an underlying database separately, usually PostgreSQL (on a sane system) or MariaDB/MySQL (on a less-sane system)). The token gets correlated to a user ID (which is as far as the tracker takes it) when it reports its metrics.
Those statistics (active torrents, bytes sent/received, total connected peers/seeds, etc.) are accumulated over time, not via database queries, but via the tracker itself. The tracker knows how many users (and which ones) are connected to it at any given time (it has to because of what it's doing). The tracker either makes those metrics available via an API (that a separate process periodically polls -- this is the "prometheus" model of "exporter+polling") or pushes them to a separate service itself (this is the "grafana alloy" model of "gather+push"). In either case, the tracker doesn't write anything to any database anywhere directly; whatever element concerns itself with those statistics fetches (or receives) them, accumulates them itself, and periodically writes them to a database somewhere.
On high-efficiency systems (which I do not allege this site is, since they're concerning themselves with this kind of resource consumption as if it's an actual problem, even though it still isn't and I'll get to that), that kind of data is stored in a TSDB (time-series database). The "classic" example of this is Toby Oetiker's
RRDtool, still used in production in countless installations today, but more modern implementations are Prometheus, Clickhouse, InfluxDB, etc. They're optimized for large-scale numeric metric aggregation, querying and reporting. None of that goes into the SQL database that's servicing the user-facing web site or even the admin stuff or back-end handling the tracker and the torrents it serves. A bittorrent tracker knows nothing about these engines.
You say "this requires polling, this is not free," which is not true. The tracker does not conduct a periodic sweep of "who was connected before that is no longer connected now?" That's not how it works. There is no "polling"; bittorrent trackers do not query clients. Bittorrent clients don't actually stay connected to the tracker under normal operation; they periodically check in (or "announce") to provide updated information on a per-torrent basis and request current peer information from the tracker (this is why if you're seeding hundreds of torrents and you restart your client, if it's a good one it won't "flood" the tracker with hundreds of "hey I'm here and seeding now!" requests all at once because it's rude and can result in throttling). Each client "check-in" is a single request, received by the tracker (and processed, or not), and ideally replied to. Clients will continue to operate as best they can in the last-known state provided by the trackers for each torrent, even if an attempt to talk to a tracker results in a timeout or even an error (this is why "unregistered torrent" errors aren't fatal -- if even one known client, reachable by any method, whether it's another tracker, or DHT, or just the cache, has a full copy of the data, other clients can still retrieve it and the swarm can survive).
Bittorrent is an event-driven peer-to-peer protocol. The tracker sits in an endless loop, waiting for requests on its configured network port. Those requests are all "announcements" from clients. One-shots. The low-level action is "connect to port, transmit request payload, await response [until timeout is reached], disconnect upon reply or timeout". The announcement includes the torrent information, currently known peers, chunks currently available to the announcing client, and bytes transferred (in both directions) since the last successful announcement. The response to the announcement is expected to include currently-known peers and seeds (on success) or an explanatory error message ("invalid authentication token," "torrent not registered," etc.) on failure. A client trying to permanently leave a connection to the tracker open is a malfunction; the protocol allows the tracker to close such connections itself without warning or notice.
Literally none of this involves inactive users. A client that is not participating in a torrent swarm is simply not talking to the tracker. The tracker maintains a cache of known clients, yes, but eventually (after a configurable period of time, ranging from hours to days) a client that hasn't announced for awhile just naturally times out of the cache and isn't mentioned again to other clients as an available/valid peer until/unless it comes back and announces again.
Now ... on the subject of performance optimization, there are "naive" ways to implement a bittorrent tracker, and I've no doubt there are low-traffic sites that do so. They are always low-traffic sites because without a bit of consideration and forethought, such trackers can never serve a high-traffic site (they will experience performance problems before they can reach "high-traffic" numbers). A naive tracker implementation will actually connect to a backend SQL database and query it regularly for torrent information (rather than relying on a REST request to some kind of middleware for it), which makes it brittle for several reasons (not the least of which being the direct dependency on the underlying database engine, its exact schema and syntax, etc. instead of abstracting it and letting a middleware handle the minutia as it should do), and an especially naive one might actually try to write raw performance metrics to an SQL database and then present them dynamically on-demand using straight SQL queries that do full table scans to gather those numbers up because they tend to not know how to use things like "indexes" and "views with aggregate functions."
I do not know exactly which tracker (home-brewed or off-the-shelf) this particular site uses, and I don't really care because it doesn't matter. What I can be sure of is nothing they're doing, no matter how they're doing it, involves their tracker actively checking for "inactive" users on a periodic polling basis. There is no reason to do so, no mechanism to do so, and nothing to "poll." You have a list of known clients and their last announce time. That's your source of truth. Nothing else is relevant (or available).
'Opens it up' as in makes room for someone who would (hopefully) utilize the tracker. As in, download, contribute, seed etc. If they got to the point of inactivity that got them disabled, what expectation is there that they will have a change of heart and come back and be 'productive' in any case? At that point, keeping their id/username/etc on hand to block them is the gatekeeping.
Again, the inactive account consumes no resources whatsoever. A few bytes in a table at most, at rest. There is nothing in flight for an inactive user. No active mechanism concerns itself with them. Like, at all. They are not "taking up a slot" someone else could be using instead. There is no "slot" to take in that sense of the word. "Slots" are created on-demand. Many bittorrent
clients also operate on that metaphor, in fact. Go look at qBitTorrent's queue manager for an example. They call it "slots" there too -- max simultaneous uploads and downloads -- but again, those are all active connections. Inactive connections just get timed out and reused elsewhere.
As for "what expectation is there they will have a change of heart?" How about sending an email? "Hey, we haven't seen you in awhile. Come on back and check out what's new!" How hard is that, exactly? Why would you automatically assume a recipient of such an email would think "oh man fuck those guys what a bunch of assholes!" and not "oh shit, I totally forgot about that site, yeah, I should go check that out tonight after work!"
I see it as removing the digital equivalent of loiterers. If you are not going to participate, fuck off and make way for someone who might. 'Paying customers only' where by downloading/seeding you pay your way as it were.
The difference is an "inactive" user is not "loitering." They are not "taking up space someone else could be using" like a car parked for a week at a convenience store with only three parking spaces in the lot. An "inactive" user is simply not currently consuming your resources or using your service. I have a Minecraft account (Mojang/pre-Microsoft). But I'm not playing Minecraft right now, and haven't played for about a month. Am I "loitering" on Mojang's/Microsoft's authentication servers because I haven't cranked it up for a month? No, not really. I'm just not using their resources right now to authenticate a local client. I am not occupying a "slot" someone else could be using on their authentication server. No such "slot" exists.
You
could make this argument for something like a hosted email service, where if you haven't logged into your web mail account (or IMAP/POP3 client) for, like, a year, you could make the argument that the mailbox is "abandoned" and can be safely closed/disabled. But that's a meaningful distinction, since even if the user hasn't logged in for a year, if the mailbox is active you still have to accept mail sent to it and you still have to store their email even if they haven't read it for a year. That's resource consumption even in the user's absence -- you're actively receiving email and routing it to that user's mailbox in their absence and storing it on their behalf. An inactive user still consumes resources on an email service.
There is no equivalent in bittorrent. Either you've announced to the tracker recently or you haven't. Either you're a peer (seeding or leeching) on a tracked torrent or you're not. If you're not, you're invisible, and consuming no resources at all.
. 
