Known pitfalls with MySQL partitioning
There are lots of pitfalls.

Simply adding PARTITIONing will not improve performance.
Change most of the indexes if you add PARTITIONing.
Don't use unless you have a least a million rows
Only BY RANGE() is useful.
It is essentially useless to PARTITION BY RANGE(the-primary-key)
There are only 4 use case for partitioning.
A PARTITIONed table is likely to be bigger than the un-partitioned equivalent.
UNIQUE and FOREIGN KEY are virtually unavailable.

More:  http://mysql.rjweb.org/doc.php/partitionmaint
SELECT  col
    FROM  PartitionedTable
    WHERE  id &gt;= 6000
      AND  id  &lt; 8000
    ORDER BY  col DESC
    LIMIT  1;

Sure, there is some partitioning pruning.  That is followed by a range scan in each picked sub-table.  Scanning a BTree is possibly faster without the pruning on top of it.
INDEX(key) has (silently) id tacked on the end.  So, this is an &quot;index range scan&quot; with or without partitioning.  But partitioning slows it down because it must do a sort if the results are not in a single partition.  (Change that id range to see how much worse things get.)
&quot;Test case error&quot;: SELECT MAX(col) .. WHERE id ... cannot be optimized, with or without partitioning.  Furthermore, the Optimizer in 5.5 performs the query more efficiently.
I ran your queries on several versions of MySQL/MariaDB.  For the first query:
Partitioned:       0.5 to 1.7 ms
Not partitioned:   0.4 to 0.6 ms

Need I say more?