From strictly a database design standpoint, ignoring potential fraud, you are right. This is bullshit. This prevents any actual auditing from occurring in the database post election.
One big issue I'm seeing with doubles/floats, that anyone with T-SQL experience can probably support, is it may potentially be introducing a lack of confidence in the calculated total. In addition to issues with arithmetic using discrepant datatypes, we also have to take into consideration that the stored procedure/view/statement used to calculate the vote totals MAY just be using an INT/NUMERIC which would cause loss of data integrity and potentially rounding to the nearest whole number.
This is supported by /u/ecloc 's post:
The votes in the report shown DO contain decimals, but GEMS automatically rounds off decimalized votes in its results so you will never see them
If I were to design a database that did anything like this (IE: one where I needed to provide a certain degree of transparency) the solution that would make the most sense would be to create a uniqueidentifier datatype (GUID) and have one exist for each vote cast. This would reside in a table with 3 columns (voter, voting for, time of ballot) with a foreign key representing who that vote was cast for (with that existing in another table.) That way you could easily, with the highest degree of transparency, show that the vote totals match the amount of votes cast.
The only reason I can think for someone to set it up this way would be either: