Are you really serious here?  Is that all you think they are doing?

Ok, I will take the other side for discussion sakes.

Do you want the hardware/monitor in your equipment limited in features because is has to meet an out dated "standard file format?"

Let's see, there is section control for example.  That is done from the coverage map.  Each company has their own method of doing it.  They need different attributes and variables.  Are you going to say they all have to do it the same and from the same file format?

Let's take AgLeader for example.  They have chosen to create a map for each product being controlled.  They can control up to 5 products, so they need 5 maps at the same time.  You propose that they be required to use shape files.  Shape files are actually 3 files in one.  So, the record 5 maps AgLeader would have to be writing to 15 files at the same time in a format that is not optimized for compressed data or file size.  They are pressing the limits of their processor now.  Can you imagine what the added load of writing to 15 file lines each with a much longer data stream would do to performance?  They have chosen instead to use a single file structure that allows them to store multiple maps in one file.

Different manufacturers have different features that REQUIRE different data structures and file formats.  That is just the way it is and the end user benefits because he has more features to chose from.

Now, let's look at this problem from another angle.  Why not post process the data after it leaves the field to put it in a standardized format for software to read.   At that point the specialized monitors are finished with the data.  They no longer need the their own special attributes or variable.  That is what FODM  (Field Operation Data Model) does.  FODM works much like printer and print drivers do in windows software only in reverse.  Windows programs output print data in a standard format.  Printer manufacturers write "printer drivers" that convert that standard format in to the format needed by their printers.  FODM was released back in 2002.  Almost all major AG software programs in use today read data using FODM.  The idea was that each equipment manufacturer would write a FODD (Field Operation Data Driver) to convert their data logs into the standardized FODM format.  Some companies have embraced the concept and are writing their own FODD's now.  The FODD's for other companies are being written by third parties.  But this concept is what allowed you to load a FODD and read AgLeader data in the free viewers that you listed in your first post.  Under this concept all software receives the same raw data.  What they do with it after that point is up to them.  That is why you see different results from the same data out of different programs.  Currently a binary version of FODM is in development.

This approach make much more sense than limiting all manufacturers to a standardized format that will limit the future expansion and features of their products.  What you need to be pushing is that all manufacturers adopt the FODM model, create and maintain their own FODDs, and come to the table for development of binary FODM.  This would achieve your goal in a manner that might possibly happen.  As much as you might like to see it, there will never be a standardized file format for all monitors/controllers in the industry.  And it is not in the best interest of the end user that there should be.