Caches are used because they are fast. To achieve this, a cache typically stores all of its data in-memory so that expensive disk reads can be avoided. Querying a relational database often involves one or more joins to other tables which can add to the complexity (for the database) of the query and slow down its execution. With a cache, you store the denormalized representation of your data in the exact form that is required by your application, i.e. if you are displaying a list of orders to a user, you don't care about keeping the Order header data separate from the Order line data when caching because all of that data is displayed together for the user.
Cached data is built from persistent application data and as a result it is not necessary to persist the cache data as it can be rebuilt from your application data, and in fact will be rebuilt every time your application data changes. As previously noted, cache systems often keep all the data in-memory so the quantity of data that can be stored is limited by your available RAM. This leads to cache eviction strategies such as LRU (least recently used) that remove infrequently accessed data so that more frequently accessed data can be prioritized.
Again, performance. However, you need to evaluate your full use case to determine what is the right solution. If your data has a high rate of modification then a cache may not provide much benefit over a relational or nosql database as the data will not live long enough in the cache to be useful. Bear in mind that this is not an either/or situation and you typically employ a cache along with a relational or nosql database as a performance enhancement.
With respect to architecture, remember that most caches are key value stores and don't support relational operations such as joins. Therefore if your data is highly relational, then a cache may be a difficult fit as you will need to set up complex dependency graphs to evict stale cache data whenever related entities change.