I know that when I'm developing Linux desktop apps, there are a few things I miss from macOS that I think go back all the way to NextSTEP:
• app bundles, their automatic discovery by and registration with Launch Services, including file-type and URI-schema handler registration (modern addition: inhibited as long as the app-bundle is marked with a quarantine xattr)
• user Launch Agents
• the Keychain
• the guaranteed availability of mDNS, and the ability for apps or services to dynamically register Bonjour/mDNS services (which can then be exposed, or not, via Sharing preferences)
• a centralized system-level caching downloader (nsurlsessiond + nsurlstoraged)
• for that matter, the ability to distinguish "cache files" from other files in such a way that cache files can be purged system-wide in response to storage pressure, with some cache files having higher importance/lower priority than other, depending on their origin app + attributes
• the ~/Library directory, with subdirs for item type (so each type can have separate policies applied—e.g. back up ~/Library/Preferences but not ~/Library/Caches.) ~/.foo/ directories are broken; the XDG standard is closer, but there are no high-level Linux APIs for e.g. accessing preferences that will always use XDG_CONFIG_DIR.
• system and user shared-support directories like /Library/Dictionaries, /Library/Sounds, /Library/Voices, /Library/Widgets, etc; where, when there is an API to access e.g. system sounds, it'll automatically merge /Library/Sounds with ~/Library/Sounds and present that as the available sounds set.
• vendor-neutral system-API-supported user state-file storage dirs, e.g. ~/Library/Cookies, ~/Library/Calendars, ~/Library/Mail, etc. (These state-file dirs were originally supposed to allow interoperation of different user agents that want to sync the same content, e.g. multiple web browsers sharing the same cookie jar. Sadly, we don't see e.g. Chrome or Firefox supporting ~/Library/Cookies as their cookie jar.)
• the guaranteed availability of a Directory Services daemon (opendirectoryd), where a computer that hasn't joined a domain is running a stub Directory Services daemon that exposes virtual records based on local configuration files; and a system accounts API that is just the client interface to the Directory Services daemon.
• Locales being available at the system level, even for e.g. kernel logging
There are also a bunch of other things that I miss from macOS that aren't part of NextSTEP but would be worthy additions, too, like the transparent exposure of filesystem-level versioning as versioned NSData; or libdispatch and its daemon.