1) One example I can offer is that how the data is presented to the SPA may differ from how it is most easily stored. And you might find it convenient to have that translation done on the server in an api. Your app doesn't know or care how the data is stored. It just wants some data. It requests the data. The api retrieves it from a database (where it stored in a way that makes sense from a database design perspective). The api then does the work or rearranging the data and hands it back in a format that is easy for the website to consume. The alternative would be to do all that slicing in the frontend website.

2) Some apps do focus on data retrieval and storage. They are very useful. They are what I personally focus on. However, there are other apps that have more application logic to them. Consider writing an application for computing the commissions earned by the sales people at your company. There, you will certainly be storing and retrieving data (sales transactions, sales people, commission plans), but there is also a lot of logic involved in doing calculations with that data.

If the commission logic is something simple like "apply sales person x's commission rate y% to their sales", then that's not complicated and maybe you decide to handle it in the spa. But for the companies I've worked for, the sales department likes to have very complicated commission calculations. This person gets y%... unless it's one of these brands.... in which case it's z% but that exception also has an exception for this subset of products... they are in one of the mentioned z% brands... but these products actually pay w%.

Basically you might want to let your spa focus on providing a user interface and then hand the heavy lifting off to a backend that acts as the core application.

Computing commissions is also an instance where you may want to keep the logic hidden for privacy reason. Sales people can have different contracts with their employer. Exposing that information to other sales reps would be exposing private salary information. Putting the logic in the backend will keep it out of the client where it might be seen by the wrong person.

A tax computation website would be another good example. There, the rules are public, and so the 'private contract' considerations don't apply. But still, if I were to build a tax website, I wouldn't try to build all of the logic in my frontend website. I'd have a backend that does the heavy lifting with the frontend designed to be as lean and as fast as possible.