The answer is "It is probably OK".
The first thing to note is that the address range in use may be outside the process image (default process image size is usually 255). You could still address PIW and PQW even if you didn't increase the process image.
In theory: When you read/write to data area that is considered consistent the you open a consistency window and while that window is open, all off the data is considered to be invalid. Reading/writing the last byte usually closes the consistency window. This can present problems if you don't read/write the entire data area at the same point in your program.
It should also be noted that some slaves don't handle sending/receiving more than 2 bytes at a time e.g. SSD drives.
I've been using profibus pretty much since it was invented and I've only come across two cases where data consistency was a problem.
Case1: S5 PLC with drives and remote I/O on profibus. The machine had been running for nearly a year when the profibus master was changed from IM308B to IM308C as part of an upgrade. The customer complained that sometimes the speed control at the rear of the machine didn't work. This seemed unbelievable but upon investigation, it was true! The speed potentiometer was connected to a 4 channel analogue input card (ET200B) where reading of the channels was distributed through the program with at least one on a timed interrupt. Analysis of packets to and from the slave revealed the problem. The original profibus master (IM308B) was re-instated and then the machine worked OK with no need to rewrite software.
Case2: S7 PLC with Motion controller on Profibus. The motion controller occupied 8 bytes but the motion control engineer insisted that the PLC should only send 7 bytes as the last byte was reserved. The motion controller governed a flying shear at the end of a roll former and the customer complained that sometimes, it would make the same component twice where the second should have been a different size. A software trap was installed to read back the data from the motion controller to confirm that the data sent had been received. The software trap took only 4 hours to find an error. The full 8 bytes were sent to the motion controller and all was well.
So in conclusion, given that you would need to read/write all the data at the same time, why not use SFC14/15?
Nick