The most obvious case for Actors are usually anything where the time to process something isn't predictable and you need to manage state of that process. So the common example is Chatroom session management where some sessions might last 5 seconds and others might last for days. Likewise Games companies have built multiplayer gaming servers using Akka. Telcos and others are common users.
For me personally I'm using Akka to mangage the processing and reprocessing of a lot of entities through some algorithms where the processing time can't be known upfront and the data is unbounded.
In terms of wanting something to tinker with then I guess building a chat application backend is probably the easiest one to demonstrate the complexity of trying to manage that (and there are also some demos in the docs as well)
The other decent alternative for some of these problems are often some flavour of messaging queues and event sourcing. E.g for the chat system you could probably shoot messages through a broker and then send a "chat finish" message. The disadvantage of this is if your broker is under heavy load then your chat app will perform linearly worse under increasing load while using the actors and state mean you can have a lot more stuff happening concurrently without the problems of waiting for events to go through a queue hence the latency advantages. Let alone if your servers are ephemeral and changing constantly then that's just another level of complexity to manually roll to keep your session state going that pretty much comes out the box to a production standard in akka persistence and sharding.
A chat system is one of the first network programming exercises. You must be trying to satisfy requirements that are beyond basics. Assuming persistent chat rooms are required, do you really need anything beyond some tables in a relational database that model chat rooms/chats?
This isn't talking about a hello world level application this is talking about an application managing complex state at scale. Maybe some bytes sent between points representing audio at the same time across several different sessions. I assure you that the problem set slack, people working on Fortnite servers etc is not the same problem set as a network programming illustration even if it's the same start point.
Can you share a use case please?