Every day I'm using mathematical reasoning such as "I reached this line of code, and since this is a structured program I am guaranteed that this variable was initialized by the time I got here", "this function can only return either a non-empty string XOR an error and has nowhere it can throw an exception so if I handle those two cases I have fully handled everything this function can do", "the error string has the username in it, and values like that must come from somewhere, so even though I've been looking for an hour and can't find it, mathematically the thing generating the error message must have access to the username", "if I construct this as a pure function that does no IO, on the flip side, no users of this function will have to worry about what errors could arise during IO, reducing the mathematical cognitive load of using this function for users".
Then you start stringing together those steps by the dozens and hundreds and thousands and millions (and you get qualitative differences there too, but those don't fit into a little post like this anywhere near as well), and you can build software.
You don't have to realize you're reasoning mathematically (proof: look around), but you're leaving useful tools in the toolchest if you don't. Even if you won't believe me about building systems this way, I can assure you those magical stories about people who can debug systems at a glance that have defeated others for hours or days comes back to someone who either formally or by experience has a fairly mathematical understanding of the system in question and was able to apply some sort of logic, even if only intuitively, to arrive at that conclusion.