Although I wonder if this should be returning an error?

Why? I think this is correct behavior.

For other types we error on truncation, so I figured we would do the same here, if you're fine with truncation why not just use floats? I dunno, I'm not very knowledgeable about decimals, so happy to defer to you 😅

This follows current rounding behavior when casting between decimals with different scales. It rounds to nearest neighbor and round up when both neighbors are equidistant. I added one more test to make it more clear.

Benchmark runs are scheduled for baseline = 8db21ea and contender = 1daf7d3. 1daf7d3 is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-rs-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java