Always mapping a given device to the same location is one of the common uses of udev, indeed. Devices can even have multiple locations, for example a disk partition might be reachable via automated numbering (e.g. /dev/sda1) but also via the label on its filesystem (/dev/disk/by-label/*), via the UUID on its filesystem (/dev/disk/by-uuid/*), and by the serial number of the disk device (/dev/disk/by-id/*). If you want to access a particular device without having to care when it was plugged it or on what port, the clearest way to do it is to add a udev rule that matches this particular hardware device and creates an entry in /dev with a meaningful name, e.g.
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1679", ATTR{idProduct}=="2001", \
SERIAL=="123456", MODE="0666", SYMLINK+="analyzer-foo"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1679", ATTR{idProduct}=="2001", \
SERIAL=="123789", MODE="0666", SYMLINK+="analyzer-bar"
Another common purpose of udev rules is to control the permissions on the device node, generally to allow a particular daemon to access it. This is what the OWNER, GROUP, MODE and SECLABEL directives are for.
A third class of reasons is to trigger certain actions when a device is plugged in. For example, you may need to upload firmware to the device, or to choose in which mode it will be used, or notify some parts of the system that a new network connection or printer is available, etc.
Best Answer
There's no reason to make a udev rule executable. They aren't executable (the kernel wouldn't do anything with them) and udev doesn't attach a special meaning to executable rule files.
A udev rule must not be writable to non-root user. A user who modifies it could inject arbitrary code that is run as root.
Udev rules don't normally contain anything confidential. Pretty much any information that's there can be revealed through
/sysinterfaces,/deventries,pscalls while aRUNdirective is running, etc.So the right permissions are 644.