In Laravel, when should I use Controllers, Services, Actions, Repositories, Model?

I don't think there's any one "correct" or "common" way of doing it. Laravel has evolved over the years, and the old timers may do things differently than newcomers. I use mostly Controller -> Model with some Controller -> Repository -> Model instances for really complicated uses or reusability. I have a few Controller -> Service things that rely on outside services. Actions are fairly new, so I haven't touched those at all.

I like to think in terms of testability. How easy is it to write unit tests? I've found in multiple frameworks and multiple languages that controllers require you to mock framework APIs. This becomes brittle as time goes on because changes to the framework affect your unit tests; this increases the blast radius of framework upgrades. Anymore, framework upgrades can happen on a monthly, if not weekly, basis.

I prefer Controller -> Service -> Model because I can isolate the interesting logic from the boundary between my application code and framework code. Controllers sit at this boundary. I don't particularly consider "services" to be the "business logic layer"; instead, logic to apply request data to my domain model lives in the service layer as an implementation of the humble object pattern. Push the interesting logic to something easier to test so I only mock my code, not some third party API.

As for using actions? That smells an awful lot like Command-Query Responsibility Segregation; it's not a bad thing, it's just a different name for a concept we already have in other tech stacks.

In broad strokes, Controller -> Model, Controller -> Repository -> Model and Controller -> Service -> Model are all common. You don't really chose one way. You need to assess the needs of each use case to determine if adding another layer of complexity tows its own weight.