If this behavior is by design, then it likely won't be classified as a bug, which might explain why you didn't get any traction last time. Fortunately, working around this is easy. Below is the code from the script tag in your codepen, with lines 28 - 34 added in order to provide the behavior you're looking for.
require([
"esri/Map",
"esri/views/MapView",
], function(
Map,
MapView,
Expand
) {
const map = new Map({
basemap: 'topo'
});
// center the view over 48 states
const view = new MapView({
container: "viewDiv",
map: map,
center: [-100, 35],
zoom: 19,
constraints: {
snapToZoom: false
}
});
view.ui.add("scaleDiv", "top-left");
const scaleDiv = document.getElementById("scaleDiv");
view.watch('stationary', () => {
document.getElementById("scaleDiv").innerHTML = `Current scale: ${view.scale}<br> Max scale: ${view.constraints.effectiveMaxScale} <br> Min scale: ${view.constraints.effectiveMinScale}`;
});
view.on("mouse-wheel", function(evt) {
var viewScale = view.scale;
window.setTimeout(function() {
if ((viewScale == view.scale) && (viewScale != view.constraints.effectiveMinScale) && (viewScale != view.constraints.effectiveMaxScale))
view.scale = ((evt.deltaY > 0) ? view.constraints.effectiveMinScale : view.constraints.effectiveMaxScale);
}, 10);
});
});
Note that the mouse-wheel event occurs before the setting of the view's scale value. As a result, when the mouse-wheel event fires, the view's scale property is still set to the value it had before the mouse wheel was moved. The window.setTimeout call is used to work around that sequence.
