1. Replacing your personal notebook with an app on a computer. That's where things like Excel, Jupyter (what I use), or EverNote, could work for you. It doesn't seem like there's much for a science-specific app to offer here.
2. Then there's electronic lab management, where you're not managing the entry of data so much as managing the people who work in the lab. This is where the software developers are active, with a variety of ideas for what lab management consists of, that probably vary depending on your discipline and industry. For instance, the website mentions protocols, collaboration, and security, none of which are issues in my work, but are very much issues in a large managed research group that is potentially in a regulated or litigous industry.
The first option works just fine for me, because it addresses the main feature of my work: Almost all of my experiments are automated, my data are produced in computer readable format, and all of my analysis is done with software. So I pretty much have a computer handy whenever I'm doing "lab" work. It would be a different story if I were, for instance, doing field or wet lab work. Then I'd probably stick with a paper notebook.
My typical notebook is mostly Python with a bit of Markdown, rather than vice versa. I'm rarely creating a linear narrative, so I often go back and add explanatory text after the fact but before I forget.
It's worth noting that I'm a lone wolf in terms of maintaining my own lab data and results. Nobody else cares how I do it, and I'm not in a regulated field. I'm in industry, so I don't publish. So it's mostly so I can figure out later what I did. At home, I've put some really obscure Jupyter notebooks on my GitHub page, which so far appears to have received exactly zero views. GitHub renders Jupyter notebooks automatically.
Alongside Jupyter, I've often got a regular Python IDE running, with programs or scripts that I use for data gathering. Most of my lab equipment is accessible via pySerial (a requirement for anything that I buy new). If you're really careful, you can script your data collection within the same Jupyter notebook that you use for analysis, but there are some hidden dangers, such as losing data stored in variables when you terminate the kernel, or over-writing files. My habit with data files is to use str(time.tim()) for file naming, so it's impossible to overwrite a file by accident.
There is a long list of cases where companies and governments have made huge decisions that were based on Excel spreadsheets where the models had fundamental flaws [0][1][2].
[0] https://www.forbes.com/sites/timworstall/2013/02/13/microsof...
[1] https://storagemojo.com/2016/08/26/excel-may-be-dangerous-to...
[2] http://www.jamaicaobserver.com/business/Excel-is-dangerous-_...
Sure, but how do they compare with the (IMHO countless) number of "right huge decisions" made on actually accurate and well devised Excel spreadsheets?
Excel is a tool, it has its limits like any tool, and should be used - like any other tool - with caution when "huge" decisions are made on it.
And like any tool you cannot put the blame on it because someone cannot use it properly.
This is defiantly a case where you want a database. You want all data to go into a write-only table (when you make a mistake the correction needs to be noted and tracked). Then use queries to do your analysis on the raw data assured that you won't make a mistake.
A database also does well for collecting meta-data: who entered this data when.
Finally a database is very useful for meta-analysis which is starting to become important.
(Now reproducible dry lab notebooks are a whole other matter)
I use monthly markdown files where I can link out to code, commits, issues, include figures etc.
To each their own I suppose.
Instead, I would suggest org-mode or maybe cherrytree.