REST/SOAP API takes care of escaping malicious script/SQL Injection

Salesforce does not automatically encode input/output. It is the client's responsibility to perform the appropriate escaping, as necessary. This is mentioned in the Platform Security FAQS.

Does the platform have any Cross Site Scripting protections?

All standard pages output encode user controlled data in the proper context it is used in.

For visualforce pages , all merge fields are HTML encoded by default.

Any cross site scripting vulnerabilities that occur from custom visualforce pages needs to be addressed with best practice recommendations and tools provided for developers.

Apex and Visualforce provide additional encoding utilities for other contexts. Developers are responsible for the proper output encoding for other non-html contexts.

Why is data not input encoded on saving to objects to protect against XSS?

The platform implements context specific output encoding for user controlled data.

Salesforce data can be presented in multitude of contexts/systems, and it is a difficult challenge to successfully anticipate the correct context for data at input time.

Standard pages are designed to properly encode data in the correct context in which it is displayed.

If input encoding is required, implement custom triggers on desired objects/fields to perform input encoding.

As the FAQ says, they'd rather not provide any extra protection in regards to XSS rather than get it wrong. It is your client code's responsibility to Do The Right Thing. No encoding is performed on storing data, and no encoding is performed when retrieving data.

The standard UI is automatically protected against XSS, as well as all clients provided by Salesforce (e.g. Salesforce1, Lightning). It is the developer's responsibility for custom clients to not fall victim to XSS attacks when using the SOAP/REST API.

First, it is the responsibility of the API implementor, and not the API caller, to make permissions checks and to never return to the user any data that the user does not already have permission to see. By the time you get the API response, it's already too late to see if the client should have access to the response. If any permissions checks are missing, that's a bug in the API.

Fortunately the REST API makes these checks for you. You cannot use the REST API to access data that you don't have permission to access. For this reason, there is no such thing as SOQL injection in the REST API and no additional checks are needed.

However, be aware that's it's possible to augment the REST API with custom calls using invocable methods. Here, too, it is the responsibility of the author of the invocable method to check for all CRUD/FLS as well as sharing in their code. It's the responsibility of the admin to not install this code in their org until they verify that these checks are being made. The user just makes the call and doesn't need to do anything else.

It's also possible for you to implement your own REST service that doesn't make these checks, but again all responsibility for security lies with the service provider, not the service consumer.

Your responsibility as the client is to make sure that you are safely storing credentials used to log into the REST API and that you are adequately protecting the data once you receive it from the server. For example, don't forward it to another party over an unencrypted connection.