The ‘classic’ environment is very much built around the idea of devices connected to the hub and communicating by Zigbee or Z-Wave, with a device handler handling the device specific stuff and mapping it to SmartThings capabilities and events. The device handlers also define a custom UI to be used in the Classic app. The DTH model fits individual Wi-Fi based devices on the local net quite well and can be stretched to handle devices on local hubs or bridges, and even those connected by the cloud. In the latter cases there are typically apps doing most of the work with the device handlers just providing essential plumbing.
In the ‘new’ environment, device handlers still work, and indeed are still the way to handle new hub connected devices. However the ‘new’ app builds its UI from metadata describing the devices and the UI used gets defined elsewhere. That process isn’t fully mature yet. There are now ways to directly integrate third party clouds to the SmartThings cloud, or to integrate devices directly to the SmartThings cloud, without basically fudging a solution using device handlers designed for hub connected devices. ‘Placeholder’ device handlers exist to stop older software falling over. Devices created with the integrations in the new environment can still work with older apps (like webCoRE), and probably should if well written, but not all do.
Perhaps when talking of device handlers I should have allowed for new integrations, but I’m not sure what terminology to use yet. The bottom line is that something somewhere is providing an interface to the hardware in a standardised fashion. If it isn’t providing an attribute saying whether colour or colour temperature is currently in use, or providing commands to manipulate the device behaviour as required, then nothing is.