You'll notice that DSC has a heavy dependency on MOF files, and there's a good reason for it.
The Managed Object Format (MOF) was defined by the Distributed Management Task Force (DMTF), a vendor-neutral industry organization that Microsoft belongs to. The purpose of the DMTF is to supervise standards that help enable cross-platform management. In other words, MOF is a cross-platform standard. That means a couple of important things:
You don't necessarily have to write a PowerShell configuration script to produce a MOF file that DSC can use. So long as you give it a valid MOF file, DSC is happy, no matter who produced that MOF file. This opens up the possibility of using third-party management tools.
Because a PowerShell configuration script produces standard MOF file, you can potentially write configuration scripts that manage non-Windows computers. Remember, your PowerShell script doesn't get sent to target nodes. The script produces a MOF, which is sent to target nodes. If the target node is a Linux computer that knows what to do with a MOF file, then you're good to go.
So the idea behind MOFs is to create a configuration management system that's cross-platform compatible. Existing configuration management systems in the Linux world (think Chef and Puppet, for example) already use MOFs the same way. So Microsoft isn't tying you to using their technology: you can manage Windows servers using anything that's capable of producing a valid MOF.
MOFs are also closely related to the Common Information Model (CIM), another DMTF standard that Microsoft originally implemented as Windows Management Instrumentation (WMI). The MOF format is used to define the classes that appear in the CIM repository - another Microsoft attempt to work and play well with others, since non-Windows computers can also implement a CIM repository that's cross-platform compatible.
It's important to understand that DSC consists of three layers:
Top: The domain-specific language (DSL) that you use to write declarative configuration scripts. This is a PowerShell language subset, and PowerShell compiles the scripts into MOFs.
Middle: The node-side functionality that accepts MOFs and accomplishes the configuration process.
Bottom: The node-side DSC resources that are called on by the MOFs to actually perform configuration tasks.
The point of this is that you can swap out the top layer for anything capable of producing the right MOF - and that the MOF format is vendor-neutral and not Microsoft-proprietary. Since anyone can provide elements of the bottom layer (and Microsoft will provide a lot), any management tool can leverage DSC. So if you've got a cross-platform management tool, and it can produce the right MOFs, then you don't necessarily need that tool's agent software installed on your computers. Instead, the tool can produce MOFs that tell the Windows DSC components what to do.