Luckily you do not need to trust in what you read from the web but you can make a test with your own data. It is not as simple as "PNG tiles are much larger than JPEG, but have better quality". That is mostly true with aerial and satellite images which can be compressed effectively with lossy jpeg method. PNG is lossless and quality is thus perfect but the difference in quality between PNG and JPEG may be invisible with bare eyes.
However, if image contains large areas of uniform colors as in topographic maps then PNG may compress more than JPEG. As a simple test I compressed a green box into PNG and JPEG (quality=80%) and file sizes were 8 kB and 30 kB, respectively.
Make a test with your own data and base your selection of cache format on that. Another thing to consider is that JPEG compression is doing bad for sharp edges like texts in printed maps.
The speed of serving tiles depends only on the file size of the tiles. If the difference is notable or not depends on the band width and total load on your server. If you will read the tiles locally I bet you will not feel any difference at all and if you feel it comes from the client which handles either PNGs of JPEGs better.
You can use ST_Dump to pull out the individual Linestrings, test those for length > 0, and then recreate the Multilinestring using ST_Collect (rather than ST_Union or ST_LineMerge, which involve actual spatial processing calculations, rather than simply combining the underlying geometries into their multi version, as pointed out by @dbaston).
SELECT
ST_AsText(ST_Collect(geom))
FROM
(SELECT
(ST_Dump(
ST_GeomFromText('MULTILINESTRING(
(-3.00712325415935 43.3437538570123,-3.00711888681593 43.3437506773148),
(-3.00693096810649 43.34361446115,-3.00692660078307 43.3436112814451),
(-3.00692660078307 43.3436112814451,-3.00692660078307 43.3436112814451),
(-3.00692660078307 43.3436112814451,-3.0068846515836 43.3436419720614),
(-3.00692660078307 43.3436112814451,-3.0069222334601 43.34360810174),
(-3.00691127288165 43.3436001834041,-3.00690690556026 43.3435970036984))'))
).geom) g
WHERE ST_Length(g.geom) > 0;
which produces:
MULTILINESTRING(
(-3.00691127288165 43.3436001834041,-3.00690690556026 43.3435970036984),
(-3.00712325415935 43.3437538570123,-3.00711888681593 43.3437506773148),
(-3.00692660078307 43.3436112814451,-3.0069222334601 43.34360810174),
(-3.00693096810649 43.34361446115,-3.00692660078307 43.3436112814451),
(-3.00692660078307 43.3436112814451,-3.0068846515836 43.3436419720614))
ie, with the line with the repeated coordinates gone. Obviously, you will want to remove the ST_AsText which is just for illustration. Note, ST_Dump is a set returning function, so you have to wrap it in parentheses followed by .geom, to get the geometry back, ie,
(ST_Dump(geom)).geom
which feels a bit strange at first.
You could do something similar to the above using a count of distinct points, but I think, testing on the length as you suggested, is the cleanest.
EDIT. It actually turns out that in this case, you don't even need to test for the length of the linestring, as ST_Union ignores the point when building the MultiLinestring back up. There are other ways to ignore certain geometry types when doing a union, such as testing with ST_GeometryType in the where clause.
Best Answer
I wouldn't expect any significant difference in performance unless you have very unusual data. There are a few places in the code where optimizations are put in for edge cases like two-point LineStrings, and you will miss out on some of these if you're storing your LineStrings as MultiLineStrings. There may be some special code paths in GEOS that you miss out on with MultiLineStrings as well.
There's a storage overhead to Multi* geometries, which will be small as long as the number of points in your geometry is small (really, it's only significant for single-point MultiPoints).
That said, if your geometries all have only a single component, there is no advantage to storing them as MultiLineStrings, so you may as well convert to LineString. If nothing else, this will make your data model more self-documenting.