That's correct. In short, in order for the sorting/filtering to work, the data needs to be something that can be natively queried and operated on with SQL.
I.e. the field type needs to support conditions in the WHERE clause such as '=' and 'LIKE' for the values, and/or it needs to support being included in the ORDER BY column list.
Large strings are LOB (Large OBject) based in the database servers, as are any of our 'rate over time' and 'value over time' fields that are BLOB (Binary Large/Long OBject) based.
The detailed reasoning is that in order to maximize the database server's capability to sort and filter the results it is fetching, you want as little non-database code as possible (performance and resource utilization reasons). So whilst in theory functions and procedures could be derived that 'crack' the formats of these fields so they can be sorted and filtered to some extent, it is similar as urmas describes and would take more than just complex SQL to resolve.
Why databases are storing data this was is a matter of performance and efficiency themselves too; my attempt to describe that would be as follows: If you can have massive blocks of data in a row and the row sizes aren't uniform, then the database cannot perform optimally (in traditional RDMS terms).
So instead of storing this data directly within the row as you logically perceive it, the database server virtualizes this information into another table and just contains a 'pointer' to it from the original row and column so it knows where to look. This pointer is a memory address, and so if you tried to sort/filter on it directly you'd just be trying to sort values like 0x12345678 vs. 0x44332211 and not the underlying data you thought was there. Instead of allowing that, the database just errors instead:
Example with LOB:
select pralloccurve from prteam order by pralloccurve asc
/
Results:
ORA-00932: inconsistent datatypes: expected - got BLOB
Example with standard 'in-row' columns:
select distinct prstatus from prteam order by prstatus asc
/
Results:
PRSTATUS
-----------
5
1 record(s) selected [Fetch MetaData: 0/ms] [Fetch Data: 0/ms]
[Executed: 27/10/15 10:02:16 CDT ] [Execution: 131/ms]
If you need that capability, it would need to be reported as (or if one already exists, then up-vote) an idea as this would require significant effort to accommodate.