[not a complete answer, but some remarks too big for a comment]
[also it focuses on games, as they are the most complex, real time application. Antialiasing for desktop UI and editors are a fairly insensitive issue and a subset thereof]
Need for Colours
A point, often forgotten from today's view is that antialiasing does need a video system systems with fine colour tuning to smoothen out edges/transitions. So either one with
a fairly large number of colours, covering in-between shades and intensities, or with
software definable colours from a larger palette than shown.
The first will require considerable more video memory, while the second needs more sophisticated video hardware using a Colour LUT. Early systems with just a few and in addition predefined colours, like on a 99/4, 2600 or C64, will not have it.
In contrast, the Atari 400/800 could select the displayed colours form a table of (up to) 128 (*1), which dis allow some really nifty shading effects and would have made a great support for antialiasing - except multiple colours within a line where quite restricted. Which brings the next point
(Bitmap)Memory
Systems, way into the 1980s were quite memory limited. Thus graphics where often character based - up to the extreme of making bitmap in special character formats. But antialiasing does need a bitmap based memory with the ability to colour each pixel separate. Even for a simple TV resolution of 320x200 (*2) needs 64000 bytes of screen memory when using with sufficient colours. An enormous and expensive amount for early games and still a lot to be handled in time by the 8 bit CPUs used thoughout the 1980s. It was way more conceivable to apply data reduction than go toward full bitmap.
Graphic Objects
Today we think in textures to be placed somewhere as objects to be manipulated. Beside the need for (3D) surfaces to place them this again is based on a flat bitmap view. For most time of game history movable graphic objects where sprites, layered on top of a background, added during line processing. These where simple insertions into the pixel stream. No processing involved. More often than not, also limited to a single colour in form of set/not set data. Their big advantage was a fee positioning without any regards to the background, this means no interaction of any kind but simple replacement. Multiple colours where usually made by layering multiple sprites at the same position. Again without any processing but a priority encoder for layers. The whole setup worked extreme well with low memory requirements and easy handling. Not as well with colours and sizes.
That's why systems went toward Bit-Blit, once bitmap frame buffers became easy available. With bit-blit operations objects of arbitrary size can be drawn on the screen - and it can be done in all colours available. While still 2D, this is already way more like today's understanding of textures than sprites are.
And since it is based on well defined operations between frame buffer (background) and object, antialiasing operations can for the first time be performed by the bit bliting hardware.
Use-Case
Each and every technology needs a use case beyond the desk of an engineer/hacker. So even with ignoring cost, there was no real need for Antialising and likewise technology until the early 1990s. Games did quite well improve from being black and white (Space Invaders) over some colours (Galaxian in 1979 was the first colour game) and more of that (Double Dragonin 1987). Games using 'simple' hardware were that advanced, that early polygon based boards like Namcos System 21 of 1987, definitely not a lightweight system, looked like a step back to users (*3). And only such systems would benefit from antialiasing.
Similar with resolution. Back in 'the good old days' hardware was fixed definition and software tightly coupled. Game hardware was made for a fixed screen resolution (*4), usually TV like. There was no real need to up or downscale for newer screens with a different resolution. If a sprite was needed in different sizes, simply having additional copies in ROM solved it without any additional hardware.
Antialiasing became not an issue before games either had to work in different resolutions or games where based on a real 3D environment. Both became a case in the 1990 and on PCs
Conclusion
So while there happened many more details in timeline and hardware variation, it is safe to state that antialiasing as we know it today does need a certain level in memory, bitmap and colour available and how objects are handled to make it viable. A level that wasn't reached (in general) before ~1990. And like all technology, it needs not only to be enabled by engineering, but it's worthless without the need for an application.
That picture changes of course, and as noted by the question, when running old game data on modern hardware. The now standard features allow to use exactly the same advantages, like smooth scaling and blending, to adapt them to today's screens.
*1 - In fact, already the 2600 offered a quite remarkable colour capacity. But with it's low 'resolution' antialiasing doesn't make much sense.
*2 - The Atari 800 could already do 384x240 in overscan and many arcade machines did use CRTs in similar or even better Resolution. Keep in mind, the limit for colour/pixel density on TV is due the transfer encoding (NTSC, PAL, etc.), not the CRT. Arcade machines didn't had that limitation, so better resolutions where quite within the CTR specs. Resulting in even more memory.
*3 - Compare the bulky graphics of Winning Run using two 68k and 5 DSPs with the smooth textures of Double Dragon with only three 8 bit CPUs
*4 - Screen resolution, the capabilities of the intended display, usually a TV (like) screen, not graphics resolution/mode displayed on this screen resolution.
for each screen pixel, the system locates the corresponding data pixel, and if the answer lands between two data pixels, instead of just picking one or the other, it calculates a weighted average of the two.
This is actually bilinear filtering, not anti-aliasing. Aliasing will still appear if you do what you described. You need to filter the texture before scaling it, in order to have anti-aliasing.