No, Dorico doesn’t currently utilise Metal directly. Dorico uses the Qt application framework, which provides a variety of graphics back-ends for drawing 2D graphics and text. Should the Qt developers decide that Metal is a priority for the framework to support, and as and when Qt’s drawing code uses Metal, Dorico will also be able to take advantage of this support.
Note that since macOS Sierra using low-DPI mode and low-DPI resolutions would not boost up (but slow down) the video performance of apps on retina MacBook models. Since retina MacBook models are already come out in 4 generations (mid-2012, late-2013, mid-2014, mid-2015), there is no reason to require users to use a MacBook Air (the only low-DPI MacBook model on sale at present) for mobile necessities.
As I see, the ideal experience regarding the UI performance of a macOS app is supposed to be as fluent as Safari.
Dorico is already fully Retina-enabled on macOS and its UI is very responsive. Provided Dorico doesn’t have to recalculate the music while it is being redrawn, redraw itself is already fast enough, even when scrolling through a large score. The issue is not the time it takes to draw the music to the screen (which could perhaps be made faster by use of a more accelerated 2D drawing framework) but rather the time it takes to calculate what should be drawn on the screen. This is why we have invested such a lot of time and energy into the application’s multi-threaded architecture, in an effort to ensure that as the complexity and size of projects increase, performance does not degrade unduly.