I expect this is by-design, insofar as an attacker can already send requests of this type (via form submission/navigation) and need not use XMLHttpRequest at all.

As noted in the fetch spec: "For requests that are more involved than what is possible with HTML’s form element, a CORS-preflight request is performed, to ensure request’s current url supports the CORS protocol."

Do The Experts agree with #1?

In mordern browser, get can send with body which navigation does not and post body with json/xml or somethings else which simple submission form does not. XHR is more powerful than other.

Re #3: If you could POST withCredentials a content-type like application/json without preflight, that would be interesting. Do you have such a demonstration?

I mean that I post with content-type: text/plain and body is json/xml :P ( some ways to bypass).

I believe you're actually asking for a change in the Standard?

https://www.w3.org/TR/cors/#simple-header
"A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain."

Web Forms (without XHR) can submit text/plain data cross-origin thusly:

   <form action="https://example.com/" method="post" enctype="text/plain" >

but how about get with body or something like that 
GET /secure/path/user?action=change_me
{
 body here
}
with content-type: text/plain, urlencode ?

I agree with Anne's analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1356995. If there's an issue here, it's an issue in the spec. I'm pretty sure the spec is internally consistent, but I'm happy to discuss it in more detail on an issue filed against Fetch.

For this bug, I'll mark it as WontFix as we're compliant with the spec and interoperable with other browsers. If you file an issue against Fetch (https://github.com/whatwg/fetch/issues/new), CC @mikewest, and we can explore the space in a little more detail. If we've missed something in our analysis of what constitutes a "simple" request, then we should fix it in a way that all browsers can learn from.

Yes, it's spec issue and Chrome is conforming to the spec.

Servers must protect themselves not to allow any unwanted side-effect by checking the origin for simple credentialed requests that won't be preceded with preflights.

----

Regarding how the CORS algorithm has been built and how the WG people has made the decision on that point, you might want to check the history using the following materials.

https://dev.w3.org/cvsweb/~checkout~/2006/waf/access-control/Overview.src.html?rev=1.152;content-type=text%2Fhtml has introduced the preflight mechanism.
https://dev.w3.org/cvsweb/~checkout~/2006/waf/access-control/Overview.src.html?rev=1.174;content-type=text%2Fhtml has introduced the simple request concept.

Check mails with cookie, cross-site, etc. in their subject from public-appformats@ archive for Jan-Mar 2008
https://lists.w3.org/Archives/Public/public-appformats/2008Feb/

s/it's spec issue/if it's an issue then filed for the spec/

Thanks for all comments.
I will think again and prepare proposal for new issue on fetch Github.

Best regards,
Severus