The Commodore 64, and possibly others, I don't know, have character codes (These map integers to characters, in the same way that ASCII does) and there are screen codes
To start with this includes the Apple II - but as well several others.
So is there a reason why not put the bitmaps in the character ROM in the same order that the characters are laid out by PETSCII? That would save people from having to do this daft, daft conversion.
For one, isn't there an OS to do that job?
The main reason is simple: Rearranging Them Saves Hardware.
The other is that rearranging them enables additional features.
For example the Apple II had only a ROM for 64 different glyphs. Arranging them in a way to suit ASCII encoding, would mean that ROM space for 128 glyphs would be needed - or additional hardware to do the transformation on the fly. That would have asked for a ROM chip double the size (*1) or a clever logic doing the transformation on the fly. Replacing a rather expensive chip with a few lines of machine code seems like a good trade off. Especially one in line with Woz' constant struggle to cut down the chip count. Isn't it?
Similarly, Sinclair's ZX80/ZX81 character set follow the same reasoning of cutting down the needed ROM space. Except here 11 punctuation characters where switched for graphic symbols to allow for 4 pixel per character cell graphics.
The SinclairSpectrum extends this to 128 codepoints to include full ASCII charset with lower case and all (*2) punctuation plus the drawing symbols.
On the PET the reasoning was a bit different. While it had a character ROM holding 256 glyphs, they where organized as two character sets of 128 each, so standard character handling could be kept as 7 bit. Further the PETSCII encoding corresponded to what the keyboard delivered, and the ROM was organized accordingly.
So while it made sense for the first PET, C64 and other 8 bit Commodore only inherited it for compatibility.
Bottom line, by separating the functionality of having ASCII on the software side, while having a different hardware representation on the CRT controller side enables ways of optimization - much like any other abstract interface does.
*1 - Or at least an additional half the size answering to the missing 31/32 glyphs twice.
*2 - Within reason.