Reasons for still using an AssemblyInfo.cs file might include

1. you want to share some of the AssemblyInfo across projects, which you can do with a file
2. you might have a code-generation process that spits out the assemblyinfo
3. the project file format doesn't yet support all the attributes you might want to use. The project Sdk knows how to auto-generate a limited set of [AssembyAttributes] from Xml Elements with matching names in the csproj file, but it doesn't support autogeneration of arbitrary [AssembyAttributes] or other metadata for your assembly.
4. AssemblyInfo.cs is “just” a source code file, you might have other metadata – whether AssemblyAttributes or classes or other – you want to keep all in one easily found place.

According to migration guide, these days, we have few flexible ways to set up assembly attributes.

1. Use old-style AssemblyInfo.cs file (create manually).

using System;
using System.Reflection;

[assembly: System.Reflection.AssemblyCompanyAttribute("...")]
[assembly: System.Reflection.AssemblyCopyrightAttribute("...")]
[assembly: System.Reflection.AssemblyDescriptionAttribute("...")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("...")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("...")]
[assembly: System.Reflection.AssemblyProductAttribute("...")]
[assembly: System.Reflection.AssemblyTitleAttribute("...")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0-dev01234567")]

2. Use MSBuild's properties to generate assembly attributes on build time (may be static in your.csproj or passed via command line arguments like /property:Version=1.0.0-dev01234567).

<Project Sdk="Microsoft.NET.Sdk.Web">
    <PropertyGroup>
        <Company>...</Company>
        <Copyright>...</Copyright>
        <Description>...</Description>
        <Product>...</Product>
        <AssemblyTitle>...</AssemblyTitle>
        <Version>1.0.0-dev01234567</Version>
    </PropertyGroup>

    ...
</Project>

Note: you may merge both solutions but avoid duplicates of assembly attributes.

You can absolutely create an AssemblyInfo.cs file and configure your assembly like you did in the past. Of course, since the properties are set using assembly attributes, you do not need to use AssemblyInfo but can choose any other file name or even an existing one.

That being said, the reason that the AssemblyInfo.cs is no longer included in the default templates is that the new SDK-style project type supports setting this information within the csproj project file.

So the usual approach to setting the version of your assembly would be to set the Version property within your project file (or have that automatically set as part of your build process). For example:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <Version>1.2.3</Version>
  </PropertyGroup>

  …
</Project>

Since this is a MSBuild property, you can also set this during the build process e.g. with dotnet build /p:Version=1.2.3.

There are also the properties VersionPrefix and VersionSuffix which can be used to automatically construct version numbers from the environment (e.g. Git commit ids, or build numbers).

In addition to the version related properties, there are also some more NuGet properties you can set in the project file, which makes the AssemblyInfo.cs mostly redundant.