always @(posedge i_clk)
A <= A + 1'b1;
always @(posedge i_clk)
C <= C + 7;
Like this the steps required to build your mental model of what is going on are smaller, and so this makes it easier to construct that model. And hopefully with fewer errors between what you think it does and what it actually does.
The repetition establishes local context, it also allows you to make changes later that will affect the one but not the other construct without making a larger change.
I find myself being extremely skittish when changing FPGA code and I tend to play it safe until stuff works and then I'll remove that short of pattern when I'm sure I won't be inserting / removing bits or changing the conditions. Initially it helps me to write out the various conditions without any kind of optimization in mind (and besides the real optimizations are usually done by the toolchain).
This is one of the main problems I have with FPGA work, I've done so much software that it is hard to get back into the mindset of programming a device and small steps really help. I also find it considerably harder to read FPGA code (my own or someone else's, of any flavor) than to read a program and to figure out what it does.
Language syntax is also a major problem. For example, if the author chose to join those two always statements he/she would have to use begin/end keywords which are ugly and cause visual "clutter". VHDL is not better in that regard, I'd say it's even worse (e.g. converting back and forth between std_logic_vector and signed/unsigned).
The only drawback I see in the author's code is that using (lots of) multiple always blocks may slow down simulation, but that's a fair price to pay if the code is more readable