"Is it true that we're talking about two different things here?" Hm, to the extent that they're different, I think this is a "two birds with one stone" issue! But I think they're naturally very closely integrated.
Let me try and explain that, firstly technologically, and secondly educationally. Let's leave aside for now the issue of teacher access to student quiz results (student logins, central server, etc) and understand "quiz" to mean a form of self-assessment in which the student attempts to solve a problem based on the activity and receives feedback about their answer. In this context, the Storytelling feature is the main mode of interaction for the student doing an activity/quiz (as opposed to a student using Kojo to learn programming whose main mode of interaction will be via the Script Editor). It is the Storytelling feature the student uses to control movement through various stages of the activity. But they can also use it to customize or experiment with various features of the activity (e.g. picking the number to factorize in the "product of prime factors" activity) and their input is the main way of the activity giving feedback to the student (e.g. checking the student can find the lower common denominator in the "adding fractions" activity). Since Storytelling occupies such a central role, interaction with it should be rich, easy, and responsive (kids prefer to click than type, and are far more likely to experiment by moving a slider from 7 to 10 and seeing the effect instantly, than to try typing in "7, 8, 9, 10" systematically). Being limited to a text form is quite a severe constraint.
Technologically, I think the needs of activity control and quiz are very similar, because they both concern the user making an input to the program, and the activity making an appropriate response. There's a nice unit circle/sin graph demonstration that we could imagine as the basis of a future learning activity. As a designer, I would use a checkbox to let the student instantly toggle animation on/off. But I would also use checkboxes to create a self-assessment exercise ("Tick any of the following statements which are true. A: sin 30 = sin 330, B: sin 45 = sin 135, C: sin 70 = sin 200, D: sin 10 = sin 170"). No instant response to the checkboxes this time, but when the student presses a "Mark me!" button, then the Storytelling should appraise their responses, give constructive feedback, and address any misconceptions that the questions have identified. The same input method has achieved two distinct purposes.
Educationally, assessment and feedback loops are an integral part of a structured learning activity. A flashy interactive demonstration that lacks self-assessment loses a lot of its educational power - a lot of the art (and hardest work!) in crafting a learning resource, lies in giving the student sufficient freedom to explore, while also giving them necessary feedback to guide them through the learning objectives. This is especially important where the demonstration is multi-stage, and it's important to check and reinforce understanding in the early stages before building up to the more advanced concepts (see e.g. Benjamin Bloom's "learning for mastery" model). In many cases it would be useful to have both the demonstration and quiz question on-screen at the same time: rather than just exploring what can be done to the animation or diagram on the drawing canvas, we can get the student to actively use it in problem-solving (in the sin graph example above, this involves reading off a graph and hopefully relating it to the position of the angle in the unit circle). So the lines between "quiz" and "activity" are blurred - some interactivities lean more towards demonstration, others lean more heavily towards assessment, but even then there are commonalities.
Sliders, radio buttons, checkboxes and drop-downs would all enrich the student experience, and widen the capabilities of interactive demonstrations and assessment activities. (I have now thought of another thing I'd like to see added to this list, sorry!!! The Color Chooser from the Script Editor would work very well in a form that can be called out to select colors. I've always used dropdowns for basic color selection in the past, but it was a major frustration for me that e.g. when I made a pattern or graphing interactivity in Excel, I couldn't just let the students choose from a palette. I'm sure you imagine the possible uses in Kojo, even if it's just for ease of experimenting which colors to use in a pattern or blending!)
There's an activity I am working on, and will email you with where I've got to at some point in the near future. I hope that will illustrate things better.