Traits

Are an alternative approach to inheritance that solves some limitations of single class inheritance, which PHP uses. Since all Eloquent models extends Model it can not extend another class. This is commonly used to share similar logic across objects. Let's imagine a couple of models have a Company relationship.

trait HasCompany {
   public function company() {
       return $this->belongsTo(Company::class);
   }
}

Now the user can easily share code from the trait, by the keyword using. This is an example and most often a more complex use case would be needed for it to make sense.

class User extends Model {
   use HasCompany;
}

Repositories

Repositories is a design pattern to abstract data layers from the application. Your logic should not care about how you store data, so if you wanted to change from Mysql to Mongodb, you would only swap out the repository and not have to change business logic.

Very opinionated here, but this is not a fitting design pattern for Laravel. Laravel has Eloquent and the database layer is therefor already abstracted. Repositories is sometimes used for Laravel applications, but rather an outlier, than a common sight. One of the main reasons for repositories, is to be data implementation agnostic, which already exists and you can swap between SQL servers flawlessly. Also Eloquents features like ::find(), scopes etc. feels like a replacement for Repositories and is quirky to use at the same time.

If you use Doctrine as the ORM, which you can in Laravel, it is the core of their architecture and repositories should be used.

It sometimes occurs that the repository pattern is used to encapsulate business logic, with a similar approach as used with services or action pattern.

Services

Is commonly used for a place to store business logic or the building blocks of your actions in your application. In traditional MVC design, Controllers should only handle input. Normally you would put your logic in Models, but they get "fat" very quickly, when this happens services is a common place to put business logic. Sometimes action or command design pattern are used, which is similar but still different.

One of the core things it solves, is to make your business logic reusable. Imaging filtering all users by an active flag, when you retrieve it in its controller.

public function all() {
    return User::where('active', true)->get();
}

Now you have your business logic, that enforces that you only work on active users, later you want to notify all active users with an email, by notifications using a command.

class NotifyUsers extends Command {
    public function handle() {
        foreach (User::where('active', true)->get() as $user) {
            $user->notify();
        }
    }
}

Now you manually have to keep business logic up to date. Next time you add a second condition or change the logic, you have to change the code in two places. In a big application where this code block is used often, it can make it quite hard to maintain the conditions without forgetting one of the places. If you make a service with this logic, you can easily utilize the same business logic across the application. While one have one place to change the code, if this logic had to change.

class UserService {
    public function all() {
        return User::where('active', true)->get();
    }
}

Everywhere you want to use this business logic getting active users, you can use the service. Therefor only having one place to maintain the logic. A call can be as simply as resolve(UserService::class)->all(). Example of the updated logic with services would be.

// controller
public function all(UserService $userService) {
    return $userService->all();
}

// command
class NotifyUsers extends Command {
    public function handle(UserService $userService) {
        $userService->all()->each->notify();
    }
}

Conclusion

The world is not black and white, you have to figure out your own approach. My advice is, do not spend time on Repositories, Laravel has a lot of features to handle data related operations scopes, getters setters etc. that conflicts with the Repository design pattern. See if a service like design approach suits you and you can utilize em. Traits is not as much an architectural design pattern, as it is a Class inheritance alternative, simply to share logic between classes.

There is no definitive answer for your question since the patterns you use highly depend on the project's complexity and needs.

However, a Service and a Repository are two different things. The Repository is a common wrapper for the model and is where you write the queries to the database. IMO you shouldn't add logic here and the sole purpose of a repository is to grab os store data into the database. The advantage of Repositories is the "easiness" to switch to other database systems.

A Service, IMO, is where you add all the application's logic.

For additional information refer to this answer.

why doesn't Laravel have a built-in repository pattern

Because there is no consensus on how they should be used if used at all.

For example, I use Repositories as an intermediary between laravel models and laravel controllers that needs the model instance to be instantiated and I never inject them into controllers but instantiate them manually when needed.

do we need to bind repositories as providers ?

As said above, there is no consensus so NO.

Depends on how you design your repositories, you can instantiate them manually, inject them into controller's instantiation (in the __contruct(UserRepository $userRepository)) as you can see in laravel from scratch tutorial from laracast or use them as service providers.