For instance here is a trackpoint from the Round Netherlands GPX. Tell me what precsion those lat / lon and elevation are claiming.
<trkpt lat="51.999610000000004" lon="5.466810000000001">
<ele>19.000000000000004</ele>
</trkpt>
I know it was a rhetorical question but I just looked up the answer anyway out of interest. Apparently, 13dp gives you angstrom levels of precision, so 15dp is going to be somewhat more precise than that.
https://gis.stackexchange.com/questions/8650/measuring-accuracy-of-latitude-and-longitude#8674
There are two points here that should not be conflated.
1) Number of track points,
2) Precision of the track points,
You can reduce the precision of the track points, I agree that 15dp is a bit overzealous 5 or 6 dp is plenty, however, the track point you have hilighted has come about due to a poor implementation in some software somewhere, of the IEEE 754 floating point standard. It's common in a lot of computer systems where designers don't know enough about the way their machine is storing the underlying bits. Many programmers look at a problem and think they will use floating point variables. Now they have 1.000000000000002 problems. This is why you can remove bloat from many a GPX, by simply taking all the values for lat/long, and making sure none of them are more than 5 or 6dp, (or even 3 or 4 if you're ok with 20+m of accuracy), this reduces the total number of bytes that the files needs to be stored. This can reduce the amount of CPU used by the device. However, as most programmers will just import the value into a variable, which will be either a 32bit, or in some cases (rare I'd say) 64bit, value, it takes the same amount of memory on the device to store 54.0, 54.123456 or 51.999610000000004, even if the actual file size for 54.0 is 14 bytes smaller. The only time that this longer variable then is slower than the shorter one is when it comes to reading the bytes off of the memory that the file is stored in, at which point you are looking at string manipulation, and saving yourself a couple of dozen or so clock cycles, when each clock cycle is done at many dozens of megahertz at least.
Thus, the precision of the lat/long points used in the gpx file, and the number of track points in the file, are two entirely separate things. I never claimed I needed angstrom level precision, and I hope that the above gives you an adequate explanation of why points like the above come about, and why it really doesn't matter, as well as how that is entirely not the point I am making.
So, having having dealt with that red herring, shall we move on to the issue of number of track points?
How about next time I go out for a longish ride, I upload my gpx file as it comes out of what ever route planner I've used, and one of you lot can reduce it to what ever you think is right, and I'll ride it, and we can see at which point I scream and switch to my original gpx[1]?
J
[1] Here, have Mondays ride:
https://ridewithgps.com/routes/28119872 it's 1992 track points, 116km, give me a gpx with less than 116 points, and also tell me how long it took you to do it, and I'll see how far I get before it drives me too insane and I use the original route.