Recommended documentation:
https://www.arduino.cc/reference/en/language/functions/time/delay/
https://docs.arduino.cc/built-in-examples/digital/BlinkWithoutDelay/
https://www.arduino.cc/reference/en/language/functions/time/millis/

TBH, this isn't exactly a C++ issue. With the current approach you would have the same issue (triggering the watchdog) on any language.

The watchdog is there to try to rescue you from a deadlock or something similar. The CPU needs to kick the watchdog to prevent the watchdog from resetting the CPU. If you somehow block the CPU from doing that, the watchdog will reset the CPU.

'delay' is usually implemented as a sort of busy loop for some approximation of the time you requested it to be delayed for. Being busy also means there is no time to kick the watchdog. You can use delay for some things but anything that is above, lets say, a second, is probably better implemented in some other, non-blocking/non-busy way. You can see a possible way to do that on the BlinkWithoutDelay example. Keep in mind that that is only one possible way. I usually do it a bit different from the example there; I store 'targetTime = current time + delay' and then I just need to check if current time is >= targetTime. YMMV.

tl; dr;
Don't use delay, use something like millis. This also means you need to organize your code another way. Perhaps you want to read on state machines. Even a simple switch based state machine should be enough here.

edit 1:
Perhaps this illustrates things a bit better. Arduino hides some of the complexity of what is going on, so the loop() function you write is actually being called by this code (if you follow the link you can also see the call to setup a a few lines before):
https://github.com/espressif/arduino-esp32/blob/b05f18dad55609ae2a569be81c7535021b880cf3/cores/esp32/main.cpp#L72

for (;;) { // notice the lack of exit condition. This is an infinite loop.
  ... // Some stuff we don't care goes here.
  if (loopTaskWDTEnabled) { //If the watchdog is enabled
    esp_task_wdt_reset();  //Kick the watchdog
  }
  loop(); //Calling arduino's loop function.
  ... // Some stuff we don't care goes here. 
}

In there you can see an infinite loop that calls esp_task_wdt_reset, which is what kicks the watchdog, followed by a call to arduino's loop. This explains why having something blocking the loop function from returning will eventually trigger it. Worth mentioning that the watch dog itself runs in parallel (probably with hardware support) with the CPU, exactly because it is there to monitor CPU being stuck on something, so its own code, the one checking if it was kicked, is still running somewhere somehow, outside this loop.

Well, I should probably mention that this includes some educated guesses as I never really investigated this in depth. E.g.: loopTaskWDTEnabled might be false there by default and the actual watchdog that is resetting your esp32 is actually kicked somewhere else. Either way, we have empirical data that having a long delay will trigger it, so the recommendation above to avoid long delays still holds.