Exchange Web Services (EWS) is a very robust mailbox accessing API for working with the content of mailboxes. It is does not due mailbox maintenance - Exchange PowerShell cmdlets are used for those types of operations. There are many benefits in using EWS over other messaging APIs. It code using EWS can be written from any language which can submit an HTTP/HTTPs request and can be done from any platform.

There are many ways to submit EWS requests. The following are what are covered by Developer Support:

Raw EWS SOAP style POSTs

Visual Studio generated proxy classes. Other proxy class generators are not supported.
Generated proxies are used by some developers - there is a lot of code out there using them. More code it seems uses the EWS Managed API. Sometimes the EWS schema has changes made to it which may require code relying on generated proxy classes to be altered if the application's proxies get regenerated. While this is a viable approach to development, it is most often better to use the EWS Managed API.

Exchange EWS Managed API.
The EWS Managed API is a .NET wrapper for doing EWS calls - it makes using EWS fairly simple. However, this API does not cover all EWS calls. The code for this API is published on GIT.

Generated proxies are used by some developers - there is a lot of code out there using them. More code it seems uses the Exchange EWS API. If generated proxy classes or the EWS Managed API have issues or limitations you can always drop back to submitting EWS POSTs.

The EWS Managed API is a web-release API and is not tied to the release of a product. So, there is no hot fix support. You can file bugs for it on GIT or one can be filed if you open a case with Microsoft. Since its open source you can also get the full source code and modify it to fit your needs. You can also check in changes and if they are accepted they may be merged in. If you are using this API and encounter issues and cannot work around it in your application code or by modifying the API then the fallback is to user a raw SOAP POST.

Some Points Of Interest:

Can be used with any language.

Works with Exchange 2007 and later.

Impersonation and delegation access are supported.

Basic, NTLM, Windows and oAuth can be used.

Code can run from a windows or web service, asp/asp.net page, windows application or any other client as long as a POST can be sent.

It can do most things that a client application would want.- its a very robust API.

Having the .Net connection limit too low will bottleneck your application. If your application is other than a simple single user client application then you may likely need to increase this number to something other than the default.

Be sure to read-up on Exchange throttling - especially in areas around EWS. Exchange throttling is for your server's protection, so clients need to be written to respect those settings - i.e. they need to self throttle if they would push back Exchange's throttling limits.

EWS has its own impersonation model. Thread impersonation is not supported. Be sure to set the x-anchormailbox header if EWS Impersonation is used since it can make a massive difference in performance and is needed in some scenarios such as notifications in order to maintain affinity.

EWS can pull generated MIME from Exchange and can also create an item with MIME. However, there is no ability to parse or otherwise work with what's in MIME.

Backgrounders:

This is a good article for an overview on Exchange development, including EWS:

The EWS Managed API can be used under PowerShell. This is truly a wonderful thing. I'm saying this because when the power of EWS is combined with the power of PowerShell and Exchange cmdlets a developer or Admin can do almost anything with Exchange.

Below is a large sample which uses the EWS Managed API and raw EWS POSTs. Its helpful as sample code, seeing how the EWS Managed API works, testing EWS operations and submitting EWS code. It contains many raw EWS samples also. This sample/tool is highly used by those who write code for EWS and troubleshoot it.