Both of those are RTL, are functionally equivalent, and likely will produce the same HW if all other things remain equal between the two synthesis settings.
Typically, "Behavioral" refers to "non-synthesizable" constructs, and "structural" refers to the use of primitives (e.g. netlist, or netlist-like). "RTL" is high-level, synthesizable constructs, as you have written (assuming the rest of the file conforms to those definitions).
Your first example is more typical, at least in terms of reset. You may, however, have logic (other than reset) that fans-in to more than one register or other combinatorial term(s) and thus compels you to create that intermediate term. Other than that, it is completely up to you and your style... and, if it is just a matter of style, I would recommend you employ the KISS-method, making it easy to follow and understand, as in your first example.
If you want to (try and) "force" the synthesizer to implement something specific, you can try writing structural code. Structural code though, is not portable, less easily changed, and typically not necessary. The tools are really good at PAR, so if you feel the need to be instantiating primitives, outside of your clocks and resets (buffers, DCMs, etc.), memories (maybe) and IO (again, maybe), you probably want to re-evaluate your part selection and/or design.
It is a good question you asked though. You should look into the religious wars regarding 1, 2, and 3-process state machines. Personally, I use 3-process state machines (combinatorial next state, combinatorial outputs, synchronous updates)... it is a hold-over approach from long ago regarding the synthesis tools interpretation, which is not as much an issue these days. Here is a fairly good discussion of it https://vhdlwhiz.com/n-process-state-machine/