Non programmers (could be game designers, artists, level designers) using the project, may feel better looking at the inspector IF the property can be changed to alter a mechanic or needed for scene edition (export all the variables they may need, but no more that the needed).
For programmers, looking at the code they will look for flow control, math, algorithms in general, the values should not matter much but what is done with the values; where you initialize the values matters but not for readability, different places mean different things (export/var/init on instance, onready/ready/enter_tree when added to the tree), setting values on ready will change all values setted after instancing.
If a specific value can make the game explode in tiny pieces, you need a value check somewhere in the code (the common ones, == null and has_node), one day you may forget it and assign that value from another place and boom!.
Once a class is instanced, it uses
_init, you can override that method on your script and set there all the values it can have that does not depend on the instance being on the scene tree, like the ones you use as simple var (or export var).
You can set more complex variables that require special initialization (or override parent class initialization).
Node and subclasses have
_ready, this is called after
_enter_tree (and called only once per instance on Godot 3), some variables may be better to (re)set on
_enter_tree than on
_ready, both work fine for variables that depend on the tree (like for checking the parent).
I have read that
onready vars are supposed to be faster than vars set on
_ready but I don't know why, and don't know if the new ready style will affect them.
If the value of a property can affect another or stored in a different way, use setters and getters, these can be used in interesting ways.