A compile-time kernel configuration can specify whether or not include each of the standard drivers included in the kernel source tree, how those drivers will be included (as built-in or as loadable modules), and a number of other parameters related to e.g. what kind of optimizations and other choices will be used in compiling the kernel (e.g. optimize to specific CPU models, or to be as generic as possible, or whether or not enable some features like Spectre/Meltdown security mitigations by default or not).
If a compile-time kernel configuration is set generic enough, the same kernel can be used with a large number of different systems within the same processor architecture.
On the other hand, the device tree is about the actual hardware the kernel is currently running on. For embedded systems and other systems with no autoprobeable technologies like ACPI or PCI(e), the device tree will specify the exact I/O or memory addresses specific hardware components will be found at, so that the drivers will be able to find and use those hardware components.
Even if the device tree describes a particular hardware component exists and how it can be accessed, if the necessary driver for it is disabled at compile-time, then the kernel will be unable to use it unless the driver module is added separately later. Or if the kernel is compiled with a completely monolithic configuration with no loadable module support, then that kernel won't be able to use a particular device at all unless the driver for it is included in the kernel compilation.
If a driver for a hardware component is included in kernel configuration (either built-in or as a loadable module) but there is no information for it in the device tree (and the hardware architecture does not include standard detection mechanisms), then the kernel will be unaware of the existence of the hardware component. For example, if the device tree incorrectly specifies the display controller's framebuffer area as regular usable RAM, then you might get a random display of whatever bytes happen to get stored in the display controller's default framebuffer area, as a jumble of pixel "noise". Or, if the display controller needs a specific initialization to start working, you might get no output at all.
In other words, the purpose of the device tree is to tell the kernel where the various hardware features of the system are located in the processor's address space(s), both to enable the kernel to point the correct drivers to correct physical hardware, and to tell the kernel which parts of address space it should not attempt to use as regular RAM.