Backup detects corruption, but CHECKDB does not
This answer is taken from an issue of the SQLskills.com newsletter written by Paul Randal, about "a database which would fail a backup with page checksum errors, but passed a DBCC CHECKDB".


  The only time this can happen is when an extent is a mixed extent
  (where the 8 pages in the extent can be allocated to potentially 8
  different allocations units – see here) and some pages are
  erroneously marked as allocated by the relevant PFS page.
  
  When that happens, DBCC CHECKDB will not attempt to read those pages,
  as it derives what pages to read from an allocation unit's IAM pages
  (the first of which lists the pages allocated from a mixed extent).
  This case is a gap in DBCC CHECKDB's corruption-detection logic.
  
  [Because] DBCC CHECKDB couldn't detect the corruption, it wasn't
  possible for it to make the repairs needed to fix them.
  So using DBCC WRITEPAGE, I worked out the changes needed in the allocation status
  for the erroneously-allocated pages, directly in the PFS page, and it
  worked!
  
  This was an extremely rare case – it's much more common that a DBCC CHECKDB
  fails but a backup would succeed.


In my opinion, Paul's resolution is way above and beyond exporting and importing the data like you did, so I think you did the right thing.