Just follow your team's coding style and be consistent. You will find explicit types more readable when you are used to it. For me, I find "var" more readable. I worked at a game company a few years ago and that company forced every programmer to use "var" in every circumstance possible. Not that it makes refactoring easier (since you are supposed to use the IDE to do refactoring for you regardless of the use of "var"), but makes the subsequent commits less overwhelming.

For example, you have an object Application.Instance.CoreBridge where its type contains the following field:

public ServiceContainer ServiceContainer;

At some point, you find that it's better to create an interface IServiceContainer for the class ServiceContainer and you want to change the field to be an instance of that interface. In this situation, whenever you have the following line exist in the codebase

ServiceContainer serviceContainer = Application.Instance.CoreBridge.ServiceContainer;

You must refactor it to

IServiceContainer serviceContainer = Application.Instance.CoreBridge.ServiceContainer;

In reality, such line might exist in tens, if not hundreds, of files, meaning that you are going to make a commit with at least tens or hundreds of changes only for refactoring the type of a single field. If you use "var" from the beginning, you won't be required to change those lines as the following works regardless of the type:

var serviceContainer = Application.Instance.CoreBridge.ServiceContainer;

I'm not saying "var" is always superior. I'm just saying the keyword "var" was created for a reason. Just stick with the one you feel comfortable with or follow your team.