What are the practical scenarios to use IServiceCollection.AddTransient, IServiceCollection.AddSingleton and IServiceCollectionAddScoped Methods?

Your understanding of all 3 scopes is correct.

Transient would be used when the component cannot be shared. A non-thread-safe database access object would be one example.

Scoped can be used for Entity Framework database contexts. The main reason is that then entities gotten from the database will be attached to the same context that all components in the request see. Of course if you plan on doing queries with it in parallel, you can't use Scoped.

Another example of a Scoped object would be some kind of a RequestContext class, that contains e.g. the username of the caller. A middleware/MVC filter can request it and fill out the info, and other components down the line can also request for it, and it will surely contain the info for the current request.

Singleton components are shared always, so they are best for thread-safe components that do not need to be bound to a request. An example would be IOptions, which gives access to configuration settings. An HttpClient wrapper class that uses SendAsync on a single static HttpClient instance would also be completely thread-safe, and a good candidate for being a Singleton.

Note that if you have a Singleton component that depends on a Scoped component, its dependency would get disposed before it. Thus a component cannot depend on another component that has smaller scope than itself.

I've seen the "just use AddTransient<T>()" view, but I don't agree.

Think about memory allocation

I hate allocating things when I don't have to, so if I know I'm creating something that's thread-safe, or that I have explicit documentation that having a singleton instance is the expected usage, then I'm creating a singleton.

AddSingleton()

Here's the ApplicationInsights TelemetryClient instance as a singleton. Their documentation says this works.

telemetryClient = new TelemetryClient(TelemetryConfiguration.Active);
services.AddSingleton<TelemetryClient>(telemetryClient);

In this project I use Azure Table Storage as well, and I've found that creating a CloudTableClient as a singleton works just fine. I don't need to keep creating instances of it for every request.

CloudStorageAccount storageAccount = CloudStorageAccount.Parse(Configuration.GetValue<string>("storageAccountConnectionString"));
CloudTableClient someTableClient = storageAccount.CreateCloudTableClient();
services.AddSingleton<CloudTableClient>(someTableClient);

In some sense, it's the equivalent of a class's readonly static property, for instance:

public static readonly CloudTableClient cloudTableClient = new CloudTableClient(...);

... there's only one instance of it in the whole application, but by using services.AddSingleton<T>() we get direct access to it using Dependency Injection.

AddScoped()

An example of AddScoped<T>() for me is that I want to embed the JavaScript that I need to get Application Insights into a web page, but I use Content-Security-Policy, so I need to put a nonce on any on-page JavaScript. I have a little bit of code that helps me do it.

services.AddScoped<ApplicationInsightsJsHelper>();

AddTransient()

I haven't found a need to use AddTransient<T>() for anything yet. It could be that I don't think of things that I have to create, every time I need them, as "services"... they're just variables that I new up. In some sense, AddTransient<T>() is a hidden use of the Factory pattern... instead of calling a static MyServiceFactory.Create() function, you have Dependency Injection (effectively) do the same thing for you.