What definitely doesn't work is one-size-fits-all. It doesn't work with hardware specs, it doesn't work with software, and it doesn't work with workflows. Managing Windows, macOS and Linux is all different enough to only get value out of it if you specialise a bit for each.
Here comes a somewhat long form answer that doesn't cover everything but covers enough, assuming you have a tech department (be it SWE, testers, platform etc) of at least 100 users.
For Windows: Use Intune and Company Portal, don't bind to AD, but use Azure as that is a requirement for native Windows lifecycle management.
For macOS: Use ABM and ADE with an MDM (like Jamf, Mosyle, Addigy, Kandji), they all come with the option to deploy a self-service portal. Don't bind to AD, don't log in with Azure, especially on single-user devices. It antithetical to lifecycle management of macOS, and doesn't help. Do escrow FV2 to MDM. Optionally you can enable DEP which enables you to do more smooth transitions for existing devices. Using MAIDs can help with resolving a user to a directory user but isn't a requirement.
For Linux: if someone wants Linux, they usually also have specific preferences for their productivity. Providing something in terms of "here, have a linux" is something I have not seen being very effective or efficient. I have had fleets where there was a default supported setup (Debian mostly, but some orgs defaulted to Ubuntu). There were two approaches:
1. Hands-off, you want Linux, you'll probably know what you're doing, just enroll into osquery so we know your posture.
2. Hands-on, you can pick our defaults or roll your own, but you'll get a SaltStack Minion configured and our Master will append your installed packages and amend your configuration as needed. Interaction is purely via chat for end-users (chatbot style in IRC or channel integration with Slack).
As for how this then works provisioning-wise:
Windows: you publish packages to the Company Portal. They can be of many shapes and sizes but we've found that ensuring that everything is actually a package and not some wrapped script is the way to keep it clean and functional. We use pseudo apps that pull in dependencies to automatically install everything you need. So if you're maintaining some legacy .NET WPF app we'd give you VS, various .NET versions, WSL2 (so you can use normal Git and interact with our services), and perhaps Rancher Desktop if you need to mock some endpoints locally.
macOS: you publish packages to the self-service app of choice. Generally they are all Installer packages but it's fine if their payload is mostly scripts since it's mostly Unix under the hood anyway. We use groups of presets so someone can click "configure me as if I were building microservices with Go and NodeJS". This would result in Rosetta, XCode, Homebrew, JetBrains, VSCode, UTM, Podman all being setup in the background and the user either getting a SwiftDialog about the process or just a notification after completion.
Linux: you publish formulas to Git and for hands-off people can read those, for hands-on you ask your chat system of choice to handle it for you. We use some jinja2 magic to pull in many formula configurations at once, and inside the formulas we try to support at least from-source, apt and dnf. But often we'll only have the automation for apt as that is where the majority of "I need Linux but I don't want to do it myself" lands (the default distro we deliver). We don't have zero-touch provisioning but instead ask users to log in on our enrolment portal and download a small Go binary that does the enrolment for them.
For all of them we keep the sources in Git so we don't end up needing a billion service desk employees writing arbitrary application profiles for multiple platforms. If someone wants to add support for their special flavour of the week, they can do that, and after a review it'll be available. That also includes OSQuery packs we use for cross-platform posture management. There is no need to hide this, and especially in a technology BU you will only create friction with opaque top-down management. They (we) will always win as technologists will find ways to do things that get the job done and hide them if needed.
This model is of course not the same as say, accounting users, or marketing or C-level. They get Chromebooks or a computer of their favourite brand that is essentially turned into an expensive web browser kiosk. The only legacy 'fat' managed systems that remain are offline systems that you might use to manage PLCs in the field. That's mostly older (but supported) windows versions that people don't want to ever reboot or shut down because the old school way of managing those means it takes almost 50% of the time of a job to boot and authenticate before you can start to get any work done. But that's often as required by some compliance or regulatory regime.