The difference is that you are able to change the argument value with your environment variables, meaning you could avoid typing roslaunch husky_gazebo spawn_husky.launch laser_enabled:="VALUE" to set the argument, instead you would do export HUSKY_LMS1XX_ENABLED="VALUE".
Now there isn't a necessity of using them, it can simply be handy for some situations (essentially for reusabiltiy). In your example the arguments are related to the sensors of your robot, if you don't have a kinect then it should be normal to have the argument kinect_enabled to false. But if you do have one, it's not something that would change everyday so you wouldn't want to call the launch files related with specifying the arg (i.e. always call roslaunch husky_gazebo spawn_husky.launch kinect_enabled:="true").
You could indeed modify the launch file to have this value to false or true by default but if someday you reuse this launch file with a different robot you would have to be aware of this modification.
This launch file is from the husky_gazebo package which is provided for users with different configurations, instead of requiring each users to change the launch file depending on their configurations, each user can use the same launch file by simply changing their environment variables. The fact that the substitution args are optenv also suggests this intention, the user doesn't need to have those variables set to use the robot because by default the husky doesn't have those sensors but you can still use it. You can find some packages (like for the turtlebot3_gazebo) using env isntead of optenv for the robot model. Using env forces the user to have this variable set (roslaunch would fail if the variable is missing) which seems normal because there isn't a default turtlebot3 model.
