Extended attributes ARE used in Windows, including by the kernel, which uses them to track various security restrictions and enforce them.
See https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/kernel-extended-attributes
Notably the USN journal of NTFS will be able to safely track changes made to files, so that filesystem snapshots or recovery of the filesystem after an unexpected brutal shutdown (caused by power loss, overheat, or BSOD and reboots) are reliable. These are short secured records added in small EA streams (generally stored themselves within the MFT record without allocating any additional extent, unless the MFT record is too small to fit all streams, in which case they will be inserted in separate NTFS extents allocated for "non-resident" attributes that don't fit in the fixed-size MFT record which is generally small and about 1KB, but where some file attributes will ALWAYS be fitted, including basic attributes, and the special attribute containing the map of allocated extents for streams that exceed the capacity, such as the default "$DATA" stream for regular file contents, or indexes for directories; which stream will fit in the MFT record depend on the size of MFT record, which may be tuned when formatting the MFT volume, but which is generally 1KB, i.e. smaller than regular "clusters" used to allocate space for extents)
Some extended attributes managed by the kernel are:
"$KERNEL.PURGE.ESBCACHE": apparently this is used by "Branch Cache" to facilitate the deployment and system updates on remotely managed hosts, allowing domains to enforce their own policies (rather than the default local policies or policies defined by default by Microsoft in Windows).
"$KERNEL.PURGE.SEC.FILEHASH": it contains a strong file hash (and the hashing algorithm used) of the file contents: this allows filesystem recovery to detect content corruption.
"$KERNEL.PURGE.SEC.CODEINTEGRITY": this small EA contains the code integrity policy flags
"$KERNEL.SMARTLOCKER.ORIGINCLAIM": it securely tracks the application that created the file (i.e. the path of its installer or MSI package containing reference signatures)
"$CI.CATALOGHINT": this contains the name of a secure *.cat file in Windows catalogs for the package containing a source for that file. Tools like "SFC /SCANNOW" or "DISM /Online Cleanup-Image ScanHealth" can inspect them, and with the help of the previous EAs, it will be be able to securely identify the original package containing the file from which it was installed (if necessary, Windows Update will be able to find, download and reinstall a copy of these packages).
DO NOT CONFUSE the last two EAs, with the "Zone.Identifier" that IE (or other web browsers for Windows) are adding on files you download from the web, or that un-archivers are adding to files you extract from a downloaded ZIP or cabinet file (or other archive formats), by copying it from the "Zone-Identifier" of the archive/cabinet file itself: these are not EAs, they are stored as "Alternate Data Streams" (ADS's) which are attributes of type "$DATA" (like the regular content of the file, except that this $DATA has a non-empty name, where as the regular content of the file has an empty name); as well, these ADS only exist if they are stored in NTFS or compatible file systems, and they are NOT checked by the kernel, but by the user interface (mainly in the file Explorer) and not always preserved when copied elsewhere (e.g. when moving such tagged files into a ZIP file). These ADS's are very weak, they are not as strong as EAs or other signatures systems (like external secure catalogs, or Authenticode signatures inside executable files, or some medias formats allowing similar signatures inside the regular content of the file; to secure the system, the kernel does not need and uses these legacy ADS, it uses Authenticode, and secure catalogs otherwise, e.g. in the Drivers database or in Windows catalogs like WinSxS). Alternate data streams are deprecated, but still used in web browsers only for that purpose, just as an hint for users, but they do not resist basic operations that users may still do, including bypassing the alert that Explorer would show them (but not always, as they are frequently not preserved). As well, web browsers may not necessarily append these "Zone.identifier" ADS, if the downloaded files use a stronger signature mechanism, or if they are downloaded by a specialized service in the background (such as Windows Update itself which uses securely signed catalogs).
Depending on tools and OS features that you use, or with some drivers, you may have other EAs defined. Many security tools and antimalware add their own EAs to various files or directories (also helping these tools to scan changes more efficiently).
If you use the Microsoft Store, or AppX deployment tools on Windows, there will also be additional EAs for setting the virtual environnement on which they will run (e.g. global settings per machine, or per domain or per user or per online "identity" depending on the remote service you'll use or with which third party you'll communicate, copy-on-write or full duplication, delayed writes or sync'ed writes, sharing options or policies, granted licences and usage rights, trackers for subscription/payment options on online services; some apps also use them also just like tracking cookies on web pages and will then store personal identifiers or preferences specific to some file contents or apps, and will be able to sync them with online personal profiles, so that you can use these apps offline, at least for a given period of time...).
If you use some cloud services (not jsut those from Microsoft), they can also sync a local copy for files you use locally the most, while allowing files to be archived online or synchronized to other devices).
Generally EAs are very small (about 100 bytes or so for most of them). Any file in NTFS/ReFS (and other supported filesystems) can have many EAs attached to them for many different applications. The way these EAs are individually encoded is application-dependant. EAs have their own names (like regular files in visible directories, and like ADS streams), except that these names are not intended to be read by humans; so these names are "technical" and not using Unicode. Some EA name prefixes are reserved by Microsoft on Windows filesystems.
Whever these EAs will be resident of not in the MFT (of NTFS or ReFS filesystems) depend on how many are present for a given file. IF they don't fit in the MFT record, NTFS will allocate some extents to locate them elsewhere on the volume. The list of EAs defined for a file are one of its streams, just like the standard attributes, or security attributes (ACLs) or the regular content, or additional streams (such as the stream that tracks that a file was downloaded from the net and may be unsafe, it may track its web domain or IP of origin, and if that domain was accessed with a secure protocol like HTTPS: this allows Windows to display authorization popups for the User, or ask for user elevation permission; ZIP/CAB files have such stream, added by web browsers and safe downloaders; and zip extracting tools will also propagate that stream on each extracted file if it may be executable or have side effects, including HTML files, fonts, Javascripts, media files, or office documents, that will be opened by default in safe mode by applications using them and that will alert the user that some embedded components like scripts or fonts may be unsafe)
It is true that some EAs were designed to provide compatibility with OS/2 or MacOS (only these EAs are deprecated), but there are still other systems added and using them. And new security systems (including in Windows itself in its kernel or in its services and features) constantly add new ones.
EAs are a key feature of NTFS (and ReFS). They also exist in other non-Windows filesystems (including Ext4 on Linux); for some filesystems that don't have native support for them, they may be stored in a separate subdirectory or in files with special names. EAs are normally not displayed in directory contents (for filesystems that implement them) and do not count in the regular file-sizes, so they can be added/removed easily without altering the regular content; they also allow different applications, services or OSes to interoperate with the same files by safely associating their own metadata. So they are safe extensions of existing filesystems (most of the time applications don't have to care about them, the OS or its services will manage them, most often for security reasons and inspection)
EAs are definitely not deprecated. In fact there are much more frequently used today, and have many variants created by the many security solutions developed (if you look at Windows 11, it uses more of them; if you are using Azure services, or join an AD domain, there will be additional EAs, if you use various security tools, not just those from Microsoft, they will add their own, some apps also use them to store DRM right trackers on your purchased medias, along with the decryption keys if needed, plus securely signed counters of devices on which they were authorized, you need to logon to the services to update these signatures or remove a device and its authorizations; EAs have plenty of possible uses, not just for security, but as well for optimizing performances by including processing hints and traces or statistics specific to a given usage; they can also be used to track backups and replications/mirrorings, better than the single legacy "ARCHIVE" bit; EAs have their own distinctive names and are creating a sort of "parallel" filesystem, except that they are generally optional and just the appropriate files or directories needing them will get those EAs).
The interest of placing EAs in the core NTFS/ReFS filesystem structure (i.e. resident in MFT records, or their extension in a non-resident special attribute used as a container for more attributes not fitting in the MFT record) is that their placement is ideal rather than using a separate store elsewhere on volumes (this would be slower, especially when working with network filesystems or hard disks and disk arrays, due to access time: EAs can be retrieved very fast at the same time as basic file attributes are loaded; and they are easier to add/remove dynamically)