I apologize in advance, but I'm going to be a bit hard on you.
First, your goal of keeping it simple is a good one that I applaud. You are right, IMO, not to bring in advanced features too early.
However, this is not the sort of code I would show to a beginner. Ever. It is the kind of code that, if submitted by an early teen would be fine, but not the sort of code that a teacher should show, lest it be emulated. If this were submitted by a college first year student, as part of some project, it would be severely downgraded.
I think students should only ever be shown code, from instructors, that they would be proud to emulate. But I think the lessons taught in this code need to be unlearned before the student can gain a proper understanding of how to program. I would use some completely different example, even if I was only interested in syntax, which I don't think you should be. You can also teach deeper lessons, just by example, by choosing what code you present to students.
Let me list a bunch of criticisms of the code, that are easily corrected, but using a different framework possibly.
Next, the formatting is a bit sloppy. A minor issue, but, if you are only a bit sloppy it won't be easy to teach them not to be.
Next, you use an identity comparison, so, in the first function neither "the circulatory" nor "circulatory system" would be accepted. This is a human factors issue and may be the main objection to the example overall. An example without such an issue could probably be easily devised. But code that frustrates uses is not what you should show beginning students. But parsing user input is a genuinely difficult problem, of course.
Next, you make assignment here to a global variable, which is a tool that shouldn't be in the beginner's toolbox. It is an advanced incantation suitable only for trained wizards. Such practice makes larger programs much harder to understand and debug. Even wizards use this "spell" sparingly.
Finally, blasting alerts from a function is likely to mislead them when you try to teach real functions (that return values). Too many students have a very hard time with the notion of "return", and think that blasting out the answer is the correct way to write a function. You are laying a trap here that can cause issues later. (Confession: I once had that misconception. It made it difficult to understand program flow.)
Overall, my suggestion is to show students only the sort of code you'd like to see from them, not just now, but in the future. Yes, keep it simple and yes, keep it motivating, but make it poetry.
The code you will get from them is probably going to be worse than the code you give to them. So, always show them something they can emulate and that any teacher would be proud to see from a student. Make it easy for them to build good habits from the start.
But note that your concerns are not the same as mine. I agree that it is too early at the start to stress things like the "say it once" principle and such. And an exercise in which you have them write the analog of your second function after giving them the first wouldn't be a bad idea. It reinforces some skills, which is a good thing.
Again, sorry to be so hard on you.
But lest I be entirely negative, let me also give an idea for something similar that works on more levels than syntax. I'll stick with functions and if-else as the primary lesson.
Show the students a function maxOfTwo, that returns the maximum of two arguments. The function doesn't "alert" but, instead returns the value. Then write a driver to test it and have the students execute that a few times. Note that the function needs no local values.
After that, work out with the students a maxOfThree, that has three arguments. Do this one two ways. First with nested if statements and again by employing maxOfTwo instead. Don't give this as an assignment, but work out the logic with them and then write the (poetic) code. You may want to introduce a local value, so it is a bit more sophisticated on two levels (locals and nesting). But using maxOfTwo twice is a truly beautiful solution that shows the power of abstraction and reduces complexity.
Then, you can assign medianOfThree to them to work on. I suggest that it might be worthwhile to have them work out the logic of it in small groups and then come up with the code. They can either write out the code individually (probably a good thing) or in their group. Then critique the code as I have done here.
And don't lose track of the point that writing functions is more about abstraction than anything else. It makes programs easier to understand. The only code hidden by the maxOfTwo function is a single if-else statement. But calling the function (assuming it has a good name) makes the intent of the program immediately clear at that point, where the expanded if statement does not. This, I think, is much more important than the ability to call the function from more than one place and know that the effect is the same. Note that obfuscated code still runs correctly, but it is the understanding that separates the programmer from the machine. So, always use intention revealing names.