Maybe it doesn't have much to do, but it's my percepction as a user: the customer support in Apple vs. Access Virus. Both make desirable, high quality products, but whereas Apple leaves some of their products outdated, Access Virus has been implementing new OS to update their old, cornerstone, mythical gear.
That work may not have an economical return in the short term, but in the long run you get a solid reputation for product and customer support.
That's probably a not-so-good example, to be honest–in Apple's case, they offer support for "vintage" products (5 ≤ age ≤ 7) until they are deemed obsolete; in general, this is much longer than the industry average, using industry-standard processors:
https://support.apple.com/en-us/HT201624, And you can continue to run Linux, say, on Apple Macintosh (Intel) hardware long into the future, if you so desire; likewise, you can build applications to run on Apple hardware, and macOS in general, long into the future, provided that you download the appropriate version of Xcode and are not bound to obsolete system calls. (In fact, you can write cross-platform code with a fair bit of reuse fairly easily.)
In Access' case, the 56K DSP platform is application-specific and uses processor-specific assembly code,
and there is no physical sound-generation hardware in the analogue domain, so you (as a user) have no options other than running Access' software, on a processor platform that is no longer being expanded by the silicon manufacturer:
https://synthmorph.com/blogs/news/access-virus-future-kemper-amp-virus-ti3. So it's particularly important that Access folds back as much 563XX development (as target product allows) into the existing range of products to extend their development life as long as possible until the edge of the pier, so to speak, is reached. Once that end-of-pier is reached, there will be a platform change, a new, general-purpose but incompatible codebase, and a true EOL for all development on the Virus platform.
In DSI's case (though I certainly cannot speak for them), there's no such illusion of long-tailed development; there are technologies which are shared across the (historical) DSI hardware devices, but they only serve to drive actual physical hardware, with real filter (and oscillator) circuits, using more-modern industry-standard DSPs and microcontrollers (with a little FPGA secret sauce thrown in for good measure,
awright, awright, awright).
The fact that we're seeing some bits of code re-use / feature re-implementation (as Robot Heart alluded to previously) across DSI product platforms is a really good thing (and I suspect that there's much more under the hood than we realize), as it means that the development costs (time, effort, priority) for high-value features can be re-used across the range, where applicable.