I can understand your concerns, although you should note that the RadEditor control is used in more complex situations. Providing a valid and proper XHTML content is vital for the Editor users.
Such cases, like the hspace and vspace attributes
are the perfect example for the inconsistent behavior of different browser engines. In Outlook they might be preferred, but when it comes to commonly used browsers, they may cause more harms and undesired side effects than the margins in Outlook.
Also, note that the RadEditor is used in a browser and this is why all tools, filters and modules of the control should use and generate valid HTML and CSS.
Indeed, there is the ConvertInlineStylesToAttributes filter, that is designed to serve the desired functionality, although for the sake of the proper Editor behavior we cannot provide a built-in functionality that does not respect the good practices for Web/HTML development.
Let me provide a simple example. Let say we have a filter that converts the margins to the mentioned hspace and vspace attributes. Currently we already know that they are not preferred in HTML5 and may lead to inconsistent behavior, but still we need them in Outlook. That is fine by know, because browsers still render correctly the DOM elements with these attributes. But in future, these attributes might be obsolete and the browser will be not able to render them correctly, setting them to some value will not make changes to the content and the images inside will act as nothing is changed in the DOM. Such behavior would be more harmful and frustrating to the end users.
Indeed, Outlook might not be able to render margins, but it is more likely the rendering engine of Outlook to be updated, so that it could render correctly margins in future.
Such inconsistent issues are best to be handled per case, according the specific scenario. If such scenarios were handled internally, every possible change and update of not so commonly used browser engines would force us to make changes according new specifications and introduce much more breaking changes of the control behavior. This would lead to a product that will force the web developers to change the configuration of the controls e.g., after every major upgrade of the Telerik controls.
This is why it is best such scenarios to be targeted as custom solutions. This way they can be supported easily and every minor change will be handled faster and more properly.
On a side note, for this case it would be better to have a custom server-side logic that ensures the correct HTML to be sent to Outlook mail. This way you will be sure that the content will be correctly rendered in the browser and after server-side logic all possible glitches to be properly translated for the Outlook render engine.
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.