There are many issues for elm_entry, elm_label about the following reasons.
So, we have to discuss improving performance of elm_entry widget and deprecating elm_label widget.
Or making a new integrated widget for text.
Adding the elm_entry widget object has big performance problems.
It changes its group(theme) when some API is called.
Let's imagine if I want to show non-editable singleline entry. The elm_entry will try to
load theme 3 times. (default -> singleline -> non-editable singleline)
Changing theme multiple times waste a lot of time.
Additionally, some features could be prepared when the feature is really needed.
2. Size calculation
The elm_entry widget uses a job for calculating its size. Because of this,
we can see some flickering issues in low performance device when a container contains elm_entry objects.
And many of developers wonder why elm_label and elm_entry have different size calculation logic.
At least, when elm_entry is not scrollable, elm_entry and elm_label must have same calculation logic and result.
3. Hard to customize its theme.
As I mentioned in the performance section, elm_entry needs many groups for supporting all of its properties.
Because of some reasons, application developers wanted to customize a theme of elm_entry widget.
And they faced a bunch of groups and mysterious properties. (source#, entry_mode, multiline, etc...)
Those properties could be used for all of other groups. But, not working.
Some of developers expect to see editable textblock part when they use "entry_mode: EDITABLE".
I think we need to reorganize Edje groups and properties for elm_entry.
1. Lack of feature
In comparison with elm_entry, many of features are not supported for elm_label.
selection, item provider(even default image loading), scrollable and etc.
We were recommend to use elm_label width for non-editable text field and performance.
But, because of features, developers change elm_label to elm_entry.
In spite of its low performance.