It applies generally to all C++ programs, not just SFML. Visual Studio has a few differences between debug and release (I'm not as familiar with G++/Clang behavior). The biggest one, as eXpl0it3r mentioned is the uninitialised variable issue.
In debug builds, Visual Studio fills variables with special values. Stack variables are filled with 0xcc. Heap memory is filled with 0xcd. When freed, heap memory is filled with 0xdd. A guard region of 0xfd is placed around allocations to detect overflow.
(A quick test with Clang in VS shows it uses 0xcc for uninitialised variables in debug too)
If your code has (as local variables):
float f;
int i;
then in debug they will have the default values: f = -107374176.0 and i = -858993460. That's how a float and an int interpret the value 0xcccccccc (meaning 4 bytes of uninitialised stack memory).
A bool that's uninitialised will always be true (it will have 0xcc or 0xcd internally, and any non zero value is true).
But all this filling has a performance hit, so in release mode it just leaves whatever is already there, so you may have random values each time it's run. So for example an uninitialised bool that's always started as true in debug will randomly be true or false in release.