For only non-delay sensitive traffic, like FTP, 250 ms is okay but such traffic, if being sourced by Ethernet and not having to deal with a reduced MTU, average packet size tends to be close to 1500. It's only when you have a common mix of traffic that the size tends toward 250 (same as about IMIX), but in this situation, where you might also have transactional traffic, you might not want to go beyond 50 ms.
You can configure different min/max within the same class as you propose, and I know of some MPLS vendors that do so, but if you totally drop lower priority traffic before higher at some point in your percentage of queue utilization, you can starve that traffic of bandwidth, much like what can happen when using PQ.
If you do mix traffic types, probably better they all share the same max value (which often also seems to be the Cisco default), but either have lower min for higher drop priority (also seems the Cisco default) and/or adjust the drop rate percentage higher.
Better for different traffic types, if possible, is to have such traffic in separate classes/queues, where you control their bandwidth allocations when there's congestion, and perhaps use WRED within each class.
You can still use the technique you describe when dealing with the same traffic that's either within or not within its contracted bandwidth (usually marked as such with a policer). Or, just skew the average drop as described, above, for different traffic types.
The way max works, at exactly max you get the specified drop percentage, the Cisco default being 10%. At max +1, you get 100% drop, just like a FIFO queue at +1. At min -1 you get no drops. From min through max -1, you can calculate your drop percentage for each queue size value by graphing a line starting a 0% at min -1 and ending at the selected drop % at max. (Again, keep in mind, current queue depth used for WRED is a moving average, so you might see 100 packets while the average is only 10 and no drops, or conversely an average max with max's drop percentage applied to every new packet yet no packets currently in the queue.)
[edit]
PS:
When working with transit delays queue sizing calculation, also keep in mind because of WRED's queue processing is based on moving averages, calculating a queue depth for some value of # ms also provides an average. Actual max latency can be very variable and high. I.e. you might need to use an average # ms delay much smaller to keep worst case delay within acceptable bounds. For example, perhaps 50 to 100 ms for bulk data transfers, and 10 or 20 ms for transactional.
