There are no clear cases where you should or should not use. It depends on the experience you want to give the user.
First of all, one of the most common but very common mistakes I see in applications that use AJAX or other similar technologies is that there is no fallback . That is, if for some reason the technology is not available, the page does not work. The first thing you should worry about is if sending with simple HTML is working perfect in all situations . Then think about giving a slightly better experience if it is available. But do not let the page stop working because the browser does not support the technology.
Although it's like, I think this technique holds true even when the fallback is not required by the client where one can ensure that the feature is available. I think the cost is very low and avoids a lot of future headache. It is a matter of methodology and organization. The cost of disorganization is usually higher. Of course the experience of each will make you choose the best path. I am not against anyone who does not want to fallback when it is not really needed according to the requirements. I just find a way worse and more disadvantageous. And the customer is not always right. Most of the time I decide for him. He decides when he has knowledge, is reasonable or I need the money: P You will do what is right for you.
Running AJAX
The only great advantage that AJAX brings is that you do not need to load another page, or the same again, to send the data and have a response. This is done transparently to the user. It makes a better impression, it's usually faster (I've seen people slow down) and can reduce the volume of data trafficked. But nothing very important. Experience is what counts.
Eventually the PHP script that will receive the request needs to be adapted to meet the needs of AJAX. But do not change in a way that prevents normal access. If this is the case, create two scripts , one to fulfill the normal submission form generating a complete page and another sending only the confirmation data that the operation was successful and informing something else that is relevant. If you can do it, the work is almost the same.
Advantage in your case
Sending each question answered really can be very interesting.
The loss or not of the data, will depend on your script PHP to handle this. It will have to persist somewhere (database, memory, etc.), have session control, etc. You'll have to control the status of the form not being completely filled, have garbage collection policies if a form is abandoned in the middle. Anyway, there are several things to think about if you want to give the user a good experience.
Have you ever wondered if there were any problems at the time of sending and you do not have AJAX? The loss is huge. With AJAX done the way you are thinking, or take advantage of the already done part or prevent the user to continue wasting their time on something that will not serve anything.
This is all complicated, having a fallback is simple. This is why many sites prefer to have AJAX. The cost of putting this feature in the right way increases. But who pays the cost is the user who will experience a lot worse.
If you're doing something real, even if you're still testing, and you're having specific questions, you're researching whether you already have it here or ask.