Short answer: disabling SafeSEH reduces the security of your program .
Details: SafeSEH is compiler protection.
On a Windows environment, SEH (Structured Exception Handler ) records are written as follows
Stack data (pointed by TEB - thread environment block) | | I) Pointer to next SEH record II | EH pointer | | II) Pointer to next SEH record III | EH pointer | | 0xFFFFFF | default EH (MSVCRT)
Typically, SEH-based attacks rely on overwriting one of the above entries and the application throwing an exception: this will merge the control flow into your code (I'm not considering DEP / ASLR, so I assume this is a known location + X). More precisely, they often "mimic the return of EH", and they bring the next "evil" pointer to go to the shellcode.
SafeSEH works by instructing the operating system to first check for validity pointer pointers (against a table of known valid EHs) before switching to them. There are several limitations to this process, and in special cases the application may remain vulnerable, but an SEH-based attack is less likely (or significantly more difficult).
When linking to a non-safeSEH compiled module, the linker will not be able to create a "trusted table" of EH locations (it simply cannot determine where and if they are valid EH), so you get an error.
Some logistical restrictions on the development of Windows, compatibility reasons and problems associated with managing addresses that fall outside the range of loadable modules (and executable image) led to the choice of disabling this option by default and leaving the user the choice to enable or not.
If your application is in desperate need of security, and you may be reporting a potential threat to the above scenario, you must enable it and recompile your modules to use it.