As always, your part your choice 
I prefer my version and prefer (in case of later mods) to have the text as text elements so later changes are easier but your method certainly works as well (it is just more complex if you want to make changes later as you have to delete the path and redo the text).
The parts format document calls for the viewbox to be set to 1px = 1 thou inch (which at 96dpi in Inkscape is a scale of 10.41667 in the document properties page. That also makes setting the hole size in the xml easier so I generally do it. It won’t affect operation as long as the height/width are set in either inches or mm so Fritzing knows the real size of the document. If the default px (and no units defaults to px) is used Fritzing will make a guess as to what the dpi was (72 for old illustrator, 90 or 96 for older/current versions of Inkscape) and sometimes gets it wrong and causes scaling issues in parts.
What can I say? Inkscape does odd things sometimes (but I’m far from an expert on svg editing so there may be a good reason for it). I think it converts to some high resolution internal number representation and sometimes has round off effects. That said when I reopen the pcb svg on Windows in Inkscape the stroke-width value is still 0 as I expect.
The breadboard svg is actually a copy of the pcb (as is icon). Schematic is really schematic but is partially wrong in that there should be only one group for the entire document and it should have the label schematic not silkscreen (which is only used in pcb) or what ever is in the fzp file (which will usually be “schematic”) in the layerId line. From your Btm_row part above the fzp file has:
<schematicView>
<layers image="schematic/Nokia_5110_btm_3f8387282d7ce92c6d9b0502a0db1f25_1_schematic.svg">
<layer layerId="schematic"/>
</layers>
</schematicView>
meaning the group currently set as “silkscreen” should be “schematic” (which is somewhat below it as another group). Same with breadboard and icon, there should be a single group for the whole drawing with the id “breadboard” (which is set in the fzp file as well). Icon is typically a copy of the breadboard svg, and Fritzing doesn’t seem to care that it isn’t called “icon” as specified in the fzp file. I suspect (but haven’t tried) that the text in group silkscreen will be omitted from the part during an svg export.
I wasn’t quite clear enough, the part exports and works in Fritzing just fine with incorrect layerIds. However if you put the part in a sketch and then do a file->export->as image->svg of one of the views when a part has has an incorrect layerId, that part won’t be in the resulting svg but the other parts (with a correct layerId) will. It is fairly minor but annoying because it causes questions when someone uses such a part in a sketch and then asks why the part doesn’t show up on svg export.
The formatting is a result of two things: I ungrouped all the svgs (which removes transforms and unneeded groups that the Fritzing exported likes to add and then ran it through my parts checking python script which converts silkscreen color to black (to show up in Inkscape), converts style commands to inline xml (because sometimes Fritzing won’t deal correctly with style commands in all cases and inline is equivelent) and removes the trailing px from font-size statements which Inkscape puts in because CSS requires it, but which breaks Fritzing (as it converts font-size with a trailing px in to a 0 font-size but only on export). As part of checking the part the input formatting is lost so the script finally runs the xml through a pretty printer which is what gives the clean output (until Fritzing’s exporter adds the groups again.) Hope this helps! Parts making is complex and poorly documented, so we tend to learn as we go.
Peter