Next BIG lesson is to explore STATE MACHINES.
The linear way you've programmed your example will inevitably end in tears.
delay() is bad as we all know, but to make your robot aware & responsive in real-time, you MUST do away with them.
In this case your millis() timing should be performed at a very high level - so the low-level functions can operate 'almost transparently' and the functions just appear to happen by themselves.
(I have a project that does a 'lot' 24x7 - and uses more than 30 concurrent millis() timers so that different parts of the system just do what they have to do - when they have to do it.)
e.g. Simple example - your states could be
STOPPED
FORWARD
BACKWARD
TURN_LEFT
TURN_RIGHT
DO_BUZZER
STICKS_MID
STICKS_LEFT
STICKS_RIGHT
Many of these can equate to functions() within your code.
Your state machine can perform one function and depending on the sensors, jump between each and other states as each sensor/operating mode is triggered. Often states are stepped through sequentially for simplicity, but there is no hard rule - and for example in collision situations, you may need to jump from turning to STOP immediately.
An extension of this is if you need to buzz, or move the sticks while moving...
You may need to implement TWO (or more) state variables - so the sticks can be triggered WHILE the chassis is moving.
Similarly, you may choose to put combined sensor states into yet another state - to identify when it is clear to activate the sticks, or turn (i.e. when there is nothing off to the side of the chassis.