I'd like to comment on WHY server-side validation support is required for client-side library Kendo UI is (from Telerik point of view MVC extentions are just helpers for rendering client-side controls).

First of all, KendoUI doesn't live in vacuum. All data entered in your controls eventually will get to server. And it must be validated there. Consequently, there should be some mechanism of returning errors from server and displaying them on client UI. I'm not sure why it's not obvious for Telerik product designers/architects. 
So for some reason Telerik support client-side validation, but do not support server-side validation mechanism for their data-bound controls. There is just no protocol for returning an error. All you offer is ability to customly implement that logic.

Now, let's consider the scenario of migrating an application from native ASP.NET MVC to Kendo UI controls. If I understand correctly, you expect developers to use native server-validation mechanisms (e.g. Html.ValidationMessageFor(), Html.ValidationSummary() extension in MVC). But the problem is that it renders different layout than kendo client-side validation messages with no chance for sync and no suggested solution.

There are also problems, associated with kendo client templates, MVVM-bound views server-validation.

My main point is that kendo UI is NOT just a set of client controls. It introduces new concepts: client-side data-bound controls, client-side template for validation messages, client-side templates in general, MVVM, ... And those concepts have design flaws, particularly in validation area, which doesn't allow easy migration to kendo controls.

PS: It's already 5 years since "It will be conveyed to our devs to be taken into account".

I'd like to comment that it is fine the way it is. In my configuration, server-side validation is handled by slick ASP.NET Web API ValidationAttributes. If the client receives 400 Bad Request from the API, it is caught and displayed via a global handler and notification control. That said, every configuration is different, and I am only using Kendo UI for client code (no server-side wrappers).

Also it's important that in case of the server errors  the popup editor to stay opened. 
The user must have the posibility to corect the error and then try again. 
The cancelChanges sample is strange because it rols back all the user's changes.

Right know the validation "framework" is by far not ready for realworld applications.

a) No way to report server errors in a consistant way.

b) possitioning validation message within a grid pop up editor is only possible by hacking the "eventArgs.sender.editable.validatable._errorTemplate" while to grid goes into edit mode.

c) The error message constuctions is worst at least. You either need to localize each error message type or you will get "lovely" messages like "firstName is required" instead of "First name is required" because they use the "name" attribute - what a joke.

d) Validation rules defined at the DataSource are not evaluated within the pop up editor.

You really should fix the basic usage scenarios within your product.

But hey - Telerik loves to reinvent the wheel instead of providing integrating points for OSS like Knockout Validation.

Great idea however I would like to chime in on it as well.

- Reporting server errors should be no different than reporting client errors as far as UI/user experience goes. Server errors should not look or behave any differently than client errors. We should be able to somehow map a collection of server errors to their corresponding input elements.

- Although the developer should have full control of the UI. There should be a well designed and through out default validation UI that should work for most scenarios. Not all developers like to spend extra time fine-tuning validation UI. It should just work.