As is well known, the class loading in WildFly is modular. A module may declare dependencies on other modules and these dependencies define the visibility rules. Moreover, a deployment is also a module (actually an EAR deployment usually consists of several modules). The core principles are explained in the documentation. Of course there is a way to add some dependencies automatically to the deployment so that developers are not required to declare these explicitly (Java EE APIs and implementations, logging providers, etc.) or even bundle into an archive. So every time an application is deployed, the responsible components from all the active subsystems are invoked for each application module. The result is a set of implicit module dependencies.

Note that a dependency does not have to be "active", i.e. the underlying technology need not be initialized (if a trigger condition is not met). However, from Weld point of view, all implicit module dependencies may have some impact on the deployment processing. To be more specific - there are subsystems/modules (JSF, JAX-RS, Batch, ...) which provide some kind of CDI integration. Typically such modules contain CDI portable extensions which observe container lifecycle events, provide own beans, register custom contexts, etc. Weld is processing all available portable extensions no matter if the module is "active" or not. The module itself may also be a CDI bean archive - in this case Weld automatically performs the bean discovery (discovers managed beans, producer methods, etc.).

The processing of portable extensions and bean archives brings additional overhead during deployment processing. Most likely the overhead won't be significant. Still it's possible to save a little bit of memory and time. Moreover it could be easier to analyze the Weld log debug output. Simply put, you can exclude unnecessary subsystems/dependencies. Basically there are two options. You can remove the extension which represents the subsystem from the server configuration (e.g. standalone.xml). However, this change will of course affect all the applications deployed. The other (more fine-grained) way is to use jboss-deployment-structure.xml (a JBoss-specific deployment descriptor) and exclude subsystems/dependencies per deployment only:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <!-- Exclude unnecessary subsystems -->
        <exclude-subsystems>
            <subsystem name="jsf" />
            <subsystem name="batch" />
            <subsystem name="jaxrs" />
        </exclude-subsystems>
    </deployment>
</jboss-deployment-structure>

See also jboss-deployment-structure.xml example. Keep in mind that this configuration affects container functionality and you should use it with caution.