I suspect this issue is actually in arrow_cast - the error message seems to come from https://github.com/apache/arrow-rs/blob/ada986c7ec8f8fe4f94235c8aaeba4995392ee72/arrow-cast/src/cast.rs#L2753

I believe this will be supported in the next arrow release

I'm working on this issue and need help here -
I added test case to debug, at the moment string to decimal conversion is using parse_string_to_decimal_native, I did not find support for e notation in this, but there is a function parse_decimal that does support e-notation.I changed the code to use parse_decimal and it works fine for cases with 4e+7 and looks like there is a bug in the parse_decimal when i provide 4e7 without + or -, for example this test case -

#[test]
fn test_cast_with_options_utf8_to_decimal() {
    let array = StringArray::from(vec!["4e7"]);
    let result = cast_with_options(
        &array,
        &DataType::Decimal128(10,2),
        &CastOptions {
            safe: false,
            format_options: FormatOptions::default(),
        },
    ).unwrap();
    let output_array = result.as_any().downcast_ref::<Decimal128Array>();
    assert_eq!(output_array.unwrap().value(0) , 40000000);
}
returns 4000000000  so it expands till the precision value.

should we replace parse_string_to_decimal_native with parse_decimal and fix this bug there?

At first glance, parse_decimal looks more mature and more efficient than parse_string_to_decimal_native.

For example, parse_string_to_decimal_native has some expensive operations that are avoided in parse_decimal:

let value_str = value_str.trim();
let parts: Vec<&str> = value_str.split('.').collect();

It does seem to make sense to do what you suggest and use parse_decimal and fix the bug there.