The key of a high level DSL like Halide is to give programmers the ability to quickly iterate across different approaches and parameterizations in implementing a parallelizable operation. Here, if we wanted to write the blur function in C++ and try out different parallelization techniques, we would need to write very low level code and incur heavy programming overhead switching between different approaches. With Halide's high level specifications, we can very abstraction specify our operations and iteration schedule, allowing us to quickly zero in on a performant schedule. This feels similar in spirit to hyperparameter searching in training a neural network.

Adding on to what @wzz said, another upside to the fact that Halide gives programmers such a clean and easy to understand interface for specifying scheduling is that it allows for an easy transition to working with tools that auto generate optimal (or near-optimal schedules) for a given pieces of code, as discussed here. In particular, the output of a Halide auto-scheduling took could be easily parsed and understood by a programmer, which would allow them to use the auto-generated schedule as a good starting point from which they could tweak parameters as necessary to improve performance even more.