In this particular context there is no good reason to use one over the other.
But in general, there are a couple things you might want to consider:
- Assigning buttons in the inspector requires no programming knowledge. So when you are working with a UI designer who can't program C#, then you just need to provide them with the methods the UI is supposed to call and they can do most of the work themselves.
- When you do it via the inspector, then you can assign a click listener on a gameObject which does not even know the button exists. When you do it in code, then the script which sets up the click handler needs to know both the button and the object which implements the click handler. Usually it's not a problem to create that connection, but it might be additional boilerplate-code you need to write, and in the end you still end up drag&dropping one object into an inspector field of another, just like you would do if you set up the button handler in the UI.
- When you do it in code, then you can do more than just assign a method. You can, for example, assign a lambda expression. Which then has access to all the variables in the scope where it was defined. That allows you to do some elegant things.
AddListener(()=>{ currentlySelectedUnit.attackTarget(enemies[i]); }) - When you do it in code, then you can assign and reassign button listeners at runtime. This is useful when you have a situation where the object which is controlled by a given button isn't known until the game is running. Or where it changes over the course of the game. You could of course solve this with another layer of indirection: The button always calls the same method of the same object (some kind of "UI Manager" perhaps), and that object knows the current context in which that action should be performed. But when you do it in code, then you can skip that additional indirection layer.