The first code is longer (two methods calls, which each do a conversion, one addition, and probably omitted some conversion back to BigDecimal). The second one is just one simple method call. I would strongly argue that the second, right way is much easier than the wrong way.
It's possible that real world code that converts to double uses temporary variables and a more complicated expression involving other operators with different precedence. Converting all that to method invocations would require refactoring the expression and if the developers are unaware of the implications (because of a lack of education in numerical methods) they might think that switching to temporary variables and preserving the expression is the safest way to adapt the code to some library that suddenly deals with that funny new numeric type. After all, if all tests (if any exist) pass...
> It's possible that real world code that converts to double uses temporary variables and a more complicated expression involving other operators with different precedence.
The primitive types in Java and their operators have always been a hack for performance in the object-oriented type system of Java. So if such code exists in the program, there can be very good reason (in particular performance), but it always has "code smell". So it always should be commented properly.
> if the developers are unaware of the implications
You do not do such a conversation if you have not read into the implications.
Obviously the first is more transparent than the second and this isn't a particularly complicated equation. Mind you that this can be mostly mitigated by splitting up the equation but that can sometimes make solutions quite opaque comparatively.
