varchar(MAX) if you don't need to, and ideally size the @Parameter the same as the column or "not too much bigger" (to allow for changes in the APP).
I have read that SQL's allocation of memory for such things is generous, and there is definite benefit in keeping the size of such objects under control.
That apart, the way that varchar(MAX) is handled (perhaps more particularly for columns in tables, and maybe not so relevant to @Paramaters) is dramatically less efficient - i.e. large data being stored out-of-row for tables, which makes it slower to "handle" than if it is in-row.
Varchar(8000) or NVarchar(4000) is the max for "in row"
The SQL for your report requires all 4 parameters to be provided (and match the data) so that does not allow for any "Blank" or "wildcard" type entries. If that's what you want that's fine of course, but you might want to consider "blank" / "wildcard" too
The other reporting requirement is "Any of THESE MULTIPLE Classification IDs that I select" which is often a user requirement, and is a bit more of a pain to program for. If you are going to encounter those you might like to try them out at your Learning Stage, so that you have a Template / proven-method once you come to build real ones.
On that tack you may also want to look at a Template for your stored procedures
I suggest you ought to have
SET NOCOUNT ON at the top (so you don't get any information-only messages at the Application end), and some sort of error handling. - e.g. THROW/CATCH
We've developed our templates over decades, and they pre-date THROW/CATCH ... I ought really to find the best-of-breed out there and see whether we should bring ours up to modern standards.