Deploying apps easily to "modern clouds" and taking advantage of their feature set requires some design decisions in your app. Generally, the biggest goal here is to be able to easily scale just by spinning up more copies, so your app needs to be able to run multiple copies in parallel serving requests without exploding. We call these types of applications "cloud native".
Additionally, if you go with a microservices style architecture (I'm not going to go into the pros and cons here), there's extra concerns with communication across the different services and similar.
Often, you'll end up reinventing the wheel and writing a ton of boilerplate to cleanly solve these issues. Also, your developers have to learn quite a bit to manage this well. Tools like dapr reduce the amount of code you need to write, and also do the best paractices for you so your dev team doesn't need to be an expert on 'the cloud' as well.
The main value proposition from what I can tell is the one of swappable components, but from my experience with other systems that try to achieve something similar it's likely a flawed one.
E.g. in a lot of ORM libraries you can _in theory_ easily swap your MySQL database for Postgres, but in practice if you actually want to make that transition (which also rarely tends to happen during the lifetime of a single project) it's such a big hassle that you didn't gain much from using the abstracted version. In the meantime you also often have to restrict yourself to the lowest common denominator that is supported by the specific implementations, so you loose out on a lot of powerful features.
Having played a bit with it I'm really enjoying it.