Primary keys, clustered indexes and partitioning
at no point while processing do we JOIN on or include date in WHERE
  clauses


All partitions will need to be touched when the partitioning column is not specified in query predicates.  Put yourself in SQL Server's shoes - how would you know which partitions to access (or not) without knowing the partitioning column value?  Consider that a singleton index seek without partition elimination will seek against every partition.  Compared to a non-partitioned table, this seek overhead will be more noticeable when few rows are returned.  There won't be as much difference with full scans, though.


  Would it not be more optimal to have a clustered primary key on
  recordID alone, does the partitioning field (date) have to be apart of
  the clustered index?


Yes, recordID alone would be more optimal but the partitioning column must be part of the clustered index key as well as all unique indexes.  The implication is that primary key and unique constraints must include the partitioning column as part of the key.


  it's only recordID that needs to be a primary key. To me date should
  not be present in the primary key or clustered index.


Without knowing your data I can't say if date should be part of the primary key or not.  Assuming not from a data model perspective, you cannot partition the primary key index without it.  One approach is to use a non-clustered non-partitioned primary key, considering the performance implications on queries.

Tiered storage for less frequently accessed data is a use case for table partitioning with different file groups.  You will still need to develop a method to either physical move the underlying files or physically move rows from one filegroup to another.  Partition SWITCH alone cannot do the job.