The rational was to design a format that can serve as a (flattened) parse tree for the JSON.
JSON handling functions in SQLite took in textual JSON and mostly spat out JSON text. So their structure was: (1) parse JSON, (2) massage in memory representation, (3) serialize JSON.
If you can come up with a format that can serve as the in memory representation, and persist that to disk, your functions can skip (1) and (3), and focus on (2).
Still, many times you'll need JSON text at the boundary, so making (1) and (3) fast are needed to.
Parsing and formatting numbers can also be an unnecessary expense, if you do that more often than you actually need it.
JSON handling functions in SQLite took in textual JSON and mostly spat out JSON text. So their structure was: (1) parse JSON, (2) massage in memory representation, (3) serialize JSON.
If you can come up with a format that can serve as the in memory representation, and persist that to disk, your functions can skip (1) and (3), and focus on (2).
Still, many times you'll need JSON text at the boundary, so making (1) and (3) fast are needed to.
Parsing and formatting numbers can also be an unnecessary expense, if you do that more often than you actually need it.