@thobie, the bare-metal purchase option for the Zybo was done to enable a lower price point for those who do not require the accessories. For the rest of our customers, adding the Accessory Kit is recommended during the purchase process.
You are not the first and the last to complain about version compatibility. It is economically unfeasible for us to update all support projects, IP and support packages provided for free four times per year for each Vivado version. Instead we made a commitment to consider the last Vivado release in each year stable and do a once-a-year update cycle. In that regard, 2017.4 is the version we are upgrading projects to. There is a question whether OOB designs should be updated at all, or kept at the version which generated the binary image shipped with the board.
The board presets are not versioned for Vivado (no version-specific releases in our git repo), because these should be forward-compatible with Vivado versions. The critical warning itself related to CK-to-DQS delays being negative appears starting with 2017.4. The negative values are due to CK trace being shorter than any of the four DQS traces.
In the early days of Zynq board design negative values where listed as sub-optimal, but not erroneous. Tree topology instead of fly-by was also among the routing recommendations for DDR3 layouts. So the Zybo was designed with this sub-optimal layout due to space constraints. During Write Leveling calibration, 0 is used as an initial value instead of the negative preset delays. After calibration, if the skew is still too low, the clock is inverted. See ug585 pg 316 for more details. All Zybos shipped to customers are functionally tested and pass the DDR3 calibration process.
Xilinx recommendations changed in the mean time, both in terms of routing topology and delay values. A trace of this can be found here: https://www.xilinx.com/support/answers/53039.html. The > 0ns requirement was introduced to be in line with non-Zynq MIG-based designs, where negative delays were never permitted.
Since these delays are board-dependent, we would need to re-design the board to make the delay positive. This is impossible with the current form-factor.
Another option would be modifying the board preset file and forcing a zero value instead of the actual delay. The tools seem to be using zero anyway for calibration. This will have to be thoroughly verified first.