Because highschool math acquainted them with the notion that a function call looks like
afunctioncall(argument)
thanks to sin(x) and cos(x) and log(x). Some people will even have vague notions of functions with multiple variable inputs like f(x,y).
Basically, highschool math introduced a lot of syntax that users will be familiar with - we're universally okay with the typical +-/* operators, for example, and ^ isn't a stretch, neither is f(). AND/OR/NOT are introductory Boolean algebra and while they're not universally taught in high-school, I find many scientists are acquainted with them (although languages using || && ! syntax are a good way to lose them). Excel's lack of boolean operators (booleans operators are functions in excel) is disappointing.
I've always found that SQL gives a good minimal arithmetic/boolean-logic toolkit for laymen. It's a good model to follow.
If you think it's normal to write sin(x), cos(x), or log(x), you've been away from math for too long. Those would nearly always be written much more conveniently as sin x, cos x, and log x. You see parentheses when you have complicated arguments, but using parens in sin(3x+4) doesn't really differ conceptually from using them in 5 · (3x+4), and nobody thinks you need parens for multiplication -- compare 5 · 3x or just a simple statement like 15 · 4 = 60.
Basically, highschool math introduced a lot of syntax that users will be familiar with - we're universally okay with the typical +-/* operators, for example, and ^ isn't a stretch, neither is f(). AND/OR/NOT are introductory Boolean algebra and while they're not universally taught in high-school, I find many scientists are acquainted with them (although languages using || && ! syntax are a good way to lose them). Excel's lack of boolean operators (booleans operators are functions in excel) is disappointing.
I've always found that SQL gives a good minimal arithmetic/boolean-logic toolkit for laymen. It's a good model to follow.